Требуется харизма.

Пару недель назад прослушал аудиокнигу Антона Калабина "Требуется харизматичный руководитель. В поисках эффективной системы управления". 

Книга особенно интересна тем, что автор - как владелец собственного бизнеса (владелец и генеральный директор группы компаний «Камео»), так и бизнес-тренер(тренинговая компания «Школа харизматических лидеров»).

Знает, что нужно его собственному бизнесе + умеет это доходчиво изложить. Местами в книге идут отсылки к его собственному опыту, и тем граблям, на которые наступил он сам, что еще больше добавляет веры автору =)

Основная идея: все мы должны идти от "бюрократического" управления к "харизматическому" и рассказывается: как развивать свою харизму и как этим процессом управлять, и из чего вобще складывается харизма. 

Автор вобще провопоставляет "харизматическое" и "бюрократическое" управление.

Но я-то теперь ё, что идти то надо, но не всегда стоит затраченных усилий или возможно для всех сотрудников, кому-то суждено и легче остаться на уровне директивного стиля. И эти стили не разные концы баррикад, а просто часть пути. 

Но тем не менее постараюсь изложить, как я понял позицию автора, чтобы не включать взаимоисключающие параграфы в смысл книги) 

Первые главы они такие "вводные" дают понять причину, следствия и необходимость харизматичного управления:

Зачем нужно харизматическое управление ?

Книга начинается с описание того, как в лихие 90-е  кучка студентов-физиков чтобы заработать на хлеб с маслом начала торговать бреющими лезвиями Джилет, и c маленького лотка сначала превратилась в контейнер с продукцией, а позже и в самого крупного поставщика в России, как лезвий так и другой продукции.

В процессе этого роста росло и количество человек, и к моменту когда в фирме было 60 человек,  бывшие физики посчитали, что добавление еще 1го сотрудника приведет к уменьшению прибыли фирмы, т.е достигли потенциала роста, ограниченного возможностями основателей и организационной структурой. 

И решили эти добрые молодцы, что чтоб дальше расти надо весь процесс формализовать, чтобы каждый знал за что он отвечает и что и как должен делать) В кратце - не сработало, описание должностных обязанностей устаревали через два дня, и их уже надо было менять, вся фирма "мучалась" и в итоге продержались они в таком режиме всего полгода) 

Ну и пришли, к выводу что надо все таки "делегировать" и развиваться в сторону доверия и ответственности, а не в сторону бюрократизации.

Собственно создание своей бизнес школы для лидеров + издание этой книги решает личные, вполне конкретные вопросы автора и тем она и хороша)

Ну и дальше шло описание в чем суть и смысл харизматического управления, которое я опущу.

Почему об этом стоит рассказывать и почему стоит его развивать ?

Как только появились первые более-менее крупные сообщества людей, так появилось и управление в его базовом виде: еще в первых рабовладельческих сообществах использовался всем известный метод "кнута и пряника" оснований на использовании мотивации к животным потребностям: еда, крыша над головой, защита и прочее.

А то харизматическое управление требовалось ну разве, что при управлении "высшими" слоями общества: бароны, дворяне, жрецы, т.е. теми для кого низшие потребности были удовлетворены. 

Соответственно в доиндустриальную эпоху "харизматическое" управление являлось секретами высших эшелонов власти, дабы "снизов" не могли пробиться революционеры и подвинуть текущих монархов. 

В индустриальную эпоху появление машинерии и автоматизации ручного труда привела, как раз к рассвету "бюрокартического" менеджмента, т.к. он неплохо подходил для формализации производства заводов, и получилось "крути гайку - делай свою работу". 

Так бывает и сейчас:  некоторые до сих пор используют принципы "грибного" менеджмента (это - оставить в тени и кормите навозом - авось чего и вырастет), но уже в постиндустриальную эпоху методы бюрокартического управления работают все меньше и меньше: уже сейчас на пособие по безработице можно жить, лучше феодалов в средние века(по уровню комфорта), а все работы которые можно описать четким набором формальных инструкций свалить на машины и роботов.

Поэтому методы харизматического управления надо развивать, как в себе, так и в подчиненных и коллегах, а не "держать их в тени".

Классические задачи управления в разрезе бюрократического и харизматического управления.

Чистый менеджмент можно свести к некоторым классам работ: 

Определение цели: 

• в бюрократическом методе - "задача"(есть четкая инструкция, как ее решать, и следование процессу - один из критериев успешности ее выполнения).
• в харизматическом - "проблема"(надо проявить инициативу и найти лучший способ ее решения )).

Анализ:

• в бюрократическом - чем детальнее расписана задача и все нужные шаги, тем лучше, анализ и жесткий контроль - дело руководства.
• в харизматическом - надо дать критерии успешности решения задачи, а понять как ее решать - дело подчиненного.

Мотивация:

• бюрократическое - материальное поощрение: процент продаж, штрафы, угрозы и т.д.
• харизматическое - в идеале - самомотивация на решение интересной проблемы при удовлетворении материальных задач.

Получение власти(так же расписывал в майнд-мапе):

• бюрократическое - "назначение",
• харизматическое - делегирование + "выбор команды".

Распеределение ресурсов:

бюрократическое - вот тебе Х ресурсов на эту задачу, Y на эту и не смей потратить ни граммом больше

харизматическое - "вот твой пул ресурсов - постарайся сделать, как дешевле и лучше".

Найм персонала:

• бюрократичесое - "идти в отдел кадров и закажи специалиста с требуемыми навыками",
• харизматическое - "подбери себе в команду подходядего человека"

Обучение:

• бюрократический - школьный подход, обязательный список курсов для посещения.
• харизматический - университетский подход, решай как обучаться сам, только покажи результат обучения в конце "семестра". 

Дальше шли достаточно интересные рассуждения про теории ближнего круга (которая считает тебя своим лидером) и дальнего круга(тех, кто знает, что ты - где-то там лидер). Вобщем-то в ближнем круге из-за излишней харизмы могут возникнуть и негативные персонажи - "фанаты", которые теряют критичность из-за за слишком сильной веры в лидера, по отношению к ним надо например свою харизму занижать(показывать, что вы обычный человек, тоже делаете косяки и т.д.)

Достаточно интересно в этом плане рассматривается разбор некоторых управленческих структур, например Мафии, где все держится на харизме ее лидеров: 

Дон с высочайшей харизмой: 

У него есть серый кардинал - советник без харизмы, но принимающий многие решения и скрытый в тени и человек без харизмы, дабы не мог сместить босса.

Так же у него есть "личный" киллер, который тоже отстоит сбоку от структуры управления дабы, он не мог как личный приближенный босса поднять свою харизму до уровня босса.

И у него есть набор сержантов, "братьев", которые "равны" друг перед другом, и соответственно ни один из них не последует за "равным братом", коль скоро тот попытается устроить революцию, с этой же целью "киллер" - не входит в состав сержантов, дабы не приблизить кого-то из них чуть ближе чем остальных .

Компания, как единый организм.

Когда читаешь мемуары основателей компании, да и вон Слава Панкратов с Сашей Орловым продвигают идеи "вижена" и "миссии", или просто читаешь где-то наша миссия : "бал-бла продвигать, бла-бла-бла клиентам, бал-бла-бла во всей России\Мире" и думаешь: "Ну что это за херня! Чего она дает - Я не понимаю.".

Но по прочтению Калабина паззл сложился чуть понятне, миссия и вижн - это инструменты принятия решений и назначения цели. 

Фактически это очень высокоуровневый аналог принятых в программировании CodeStyle & Architecture(Ux/чо-угодн) Guidelines. 

И это приоритеты: сначала доля рынка, потом клиенты, и только потом может быть прибыль, или прибыли может вобще и не фигурировать в миссии. В ИТ guidelines тоже часто определяют приоритеты: поддерживаемость, тестируемость, удобство пользования. стабильность, и посмотрев на них можно выбрать лучшее из 2х-3х вариантов решений.

В общем-то когда компания совеместно выработала для себя это видение, тогда и начинается именно "компания", а не "организация" и всем понятно:  кто, что и зачем делает. И ценности компании "трассируются" на конкретные задачи и цели. 

Еще тут -же  упоминалось про корпоративную культуру, мифы, ритуалы и прочие штуки, но они не вызвали чувство "Эврика!" в голове) Хотя рассуждения были тоже интересные.

Дальше уже идет достаточная конкретика и расскажу, что зацепило: 

Усиление личной харизмы: Например, упоминается новая для меня мысль, что харизматический лидер - это архетип Отца - он сильный, здоровый уверенные, и заботиться о своих "детях". И личную харизму можно развивать создавая себе такой образ. 

В этом разрезе интересно выглядит образ женщины-лидера: она тоже должна соответствовать "отцу", а не "матери".

Усиление харизмы компании: 

Тут были проведены аналогии с личностью и приведена попытка провести аналогии с личной харизмой: назвали бы вы свою организацию: зрелой, спокойной, уверенной и заботливой. 

Или она глупая и неповоротливая ? 

Те же методы что применимы к человеку, применимы и к организации в целом.

Снижение личной и чужой харизмы: 

Черезчур харизмы - это иногда и плохо, я уже упоминал про "фанатов". Еще бывает в продажах можно выступить, как "ведущим" так и "ведомым" и мастер-продавец умеет отыгрывать обе роли. Приводяться опять же методы, как "позитивного" снижения харизмы - "да он такой же как мы, тоже человек а не супер-звезда" , так и негативного "да он - лох и его девушки не любят".

Стили управления: 

"Отец" - он тоже разный:

есть  отец - "командир - отец солдатам", 

а есть царь - "царь-батюшка".

И применяю один в работе, в жизни придется ему соответствовать царь-батюшка уже не может позволить себе выехать с коллегами поиграть в футбол или пообедать в столовой с рядовыми сотрудниками, а отец - запросто.

Царю необходим тронный зал, а отцу - достаточно рабочего кабинета, и т.д. 

В общем-то если был выбран 1 путь, то сменить его на переправе уже не получиться иначе это вызовет недоумение и придется ему следовать всю жизнь.

Итого:

Книжка жутко полезная, я с не во всем согласен внутренне, но то, что некоторые загадочные моменты она просветила - это жуткий плюс. Занес для себя в категорию "mustread". 

Кроме того она доступна в виде аудиокниги и ее можно слушать в "трее", хотя качество страдает - записать\выписать умную мысль некуда, или можно начать обдумывать мысль и пропустить часть книги.

Июньские похождения)

Довольно интересно прошел, ну верней подходит к концу, июнь) Помимо уже отфидбеченного девконфа, успел побывать на agilecamp в Самаре & laf 2011 в Иваново.

Про ажайлкемп уже написали 5-ок отзывов (раз, два, три, четыре), потому сам буду краток и донесу тока, суть и что еще помню через неделю =)
Зато имею возможность сравнить.
Спойлер: аналитики - серьезнее =) Если на ажайлкампе постоянно где-то кто-то ржет, а докладчики шутят, то аналитики  - только на афтерпати, ну или мне так показалось)

Небольшой дисклеймер: все написанное мое субьективное имхо, если что-что написал не понравиться, меня можно найти в моем круге добавить и высказать, все что вы обо мне думаете =)

Сперва про кемп:


День первый:
В общем-то событие было ближе по формату к выездной встрече-тусовочке. Зубров типа Кенинберга (как на ажайлдейс не зазвали), ничего особо вопиюще-нового рассказать видимо не планировали, а планировали, как летний отдых + полезное дело.
Сам я ходил, на продуктовую секцию, т.к. про все инженерные практики знал и слышал, как минимум на ажайлдейз 2011 или читал\ пробовал сам.

Правда был необычный формат целого дня мастер-классов, но сдается мне он сыграл отрицательно, т.к. была мысль сделать "продукт", и потому все мастерклассы были завязаны на то, что получалось в предыдущем, и в общем-то качество постепенно падало.

И к 3ему мастер-классу про сторри-маппинг и бумажное проектирование от Максима Гапонова, оказалось, что продукт получился слишком не качественным, что привело к смуте и разброду), хотя что-то полезное вынести из него можно было.

Единственное что было ново: доклад Бориса Вольфсона про Риск-менеджмент в Ажайл проектах, так, как никто такого еще не пытался рассказывать. Хотя сдается мне от обычного риск менеджмента в не ажайл-проектах он отличается не сильно)
Ну или я что-то упустил). В общем первый день, прошел да и ладно: было заведено пара-тройка новых знакомств, поддержано пара бывших, и поучаствовал в афтер-пати)


День второй
Но второй день был гораздо лучше (положа руку на сердце скажу, чтоб если был только второй день кемп только б выйграл =).
Проснувшись и добравшись до корабля, загрузившись кегами с пивом и снэками - загрузились на кораблик. Честно говоря подумал, что дальше пива и снеков дело уже и не пойдет) Но постепенно разговоры перешли в профессиональную область, в трюме на корме и палубе начали обсуждать интересные и животрепещущие темы)

Если в первый день можно было поболтаться в коридоре, т.к. не боялся что-то пропустить, то на корабле и после стыковки с островком, на которые выгрузили флипчарты и разбились по кучкам хотелось быть в 3х местах одновременно) Часть зубров делились своими Agile-WTF-ами в трюме на корабле, Антон Катков рассказывал свой опыт примения ажайла в Flexis и ревьювил все, то что успел попробовать, Солнцев и Алименков из XpInjection терли темы за жизнь, о том как важно быть эрудированным в разных областях, как например Хиругия и Пмство, и что ИТ - оно новое и переизобретает велосипеды и активное заимствует у более древних профессий типа военных (сразу вспоминаем Влада Балина), политиков и т.д. =)

Ажайл для Дизайнеров
Очень сильно запомнился доклад Алишера Якупов про "Ажайл для дизайнеров", видел его слайды до этого в френдфиде но в живую услышать - гораздо круче.

 Суть Алишер перешел в Мейл.Ру и в частности Одноклассники, чтобы навести порядок и систематизировать дизайн, причем переходил как дизайнер и должен был заработать авторитет и признание коллег, чтобы получить звание "главного" дизайнера\проектировщика\не суть.

До его прихода в дизайне был "бардак", не было единых гайдлайнов, были 10 разных иконок на удаление, отсутствовали единый лейауты и т.д. и все потому, что были компонентный команды, которые никак особо и не взаймодействовали. И дабы исправить эту ситуацию и привести ее к четкому, структурированному виду были организованы "пятницы-систематизатницы" на которых дизайнеры, по слоям типа: лей-ауты, блоки, иконки, что-то еще там рисовали те элементы, что они используют постепенно они собрали всю библиотеку используемых элементов(и наверно пришли в ужас).
И после этого смогли увидеть избыточность не консистентность и прочие нехорошие вещи, результатом обработки всего этого месива стала ...
"Азбука" - гайд-лайн по дизайн элементам системы, из которого уже можно было собирать готовые прототипы, и которая постепенно дополнялась если в ней чего-то не хватало.
Интересным оказалось, как была построенна система поддержки ее в актуальном виде, за каждый слой был назначен ответственный, в обязанности которого входило поддержка вики в актуальном виде И принятие решений по включению новых элементов в нее.
Как сказал сам Алишер, это сделало систему гораздо более удобной для дизайнеров, т.к. теперь менеджер не мог придти и сказать - "а давай здесь сделаем синюю кнопку", т.к. за кнопки их цвет и общий стиль отвечает "вон-тот чувак", иди и убеди его, что надо добавить кнопку синих цветов в "общую палитру".

Помимо этого рассказал интересные инсайды, что вот чуть-чуть добавили зеленого к кнопке и кликабельность регистраций увеличилась на 4-5%, метрики - СИЛА) Можно не опрометчиво говорить вот такая кнопка - лучше, а привести данные и точно сказать - она лучше на 5% =)

Было много еще интересного, но я все не запомнил, а записать - зафейлил)

А теперь про ЛАФ.

All you need is ЛАФ!

На этот раз писал поболее и меньше опирался на память)

Немного об организации:
Мероприятия, проходило оно в Иваново и в Субботу-Воскресенье, с одной стороны хорошо: нет таких диких цен на аренду(да и вобще помещение предоставлял НПО Консультант) и стоимость участия была чисто символической , с другой стороны туда можно было доехать выехав в 4-5 часов утра, что многие и сделали, в результате чего были довольно сонно-убитые (по крайней мере Я =)).

Компания показалась мне чуть ли не семейной, т.к. аналитиков судя по всему в России довольно мало и все друг-друга знают почти в лицо, еще были товарищи из Белоруси в лице 2х человек.

Конференция так же состояла из 2х дней и оба были хороши =)

День первый:
По прибытия нагрузился кофе, так, что вобще перестал ощущать что-то из внешних раздражителей кроме нагретой головы и "познакомился" с Иваном Касатенко, с которым перекинулся парой фраз еще на ДевКонфе, дождавшись начала конференции и обсудив с Иваном и его коллегой-девушкой (сорри не записал как зовут =)) необычно-высокую плотность девушек на квадратный метр (наверно 20-30 % человек) для ИТ-конференции (так, вот куда уходят девушки в Ит - в аналитики =)).

Хотелось сходить на Александра Байкина, на после того, как стало понятно, что это не повторе или ошибки, а мастер-класс про юз-кейсы на полдня решил, что послушав проведу время полезнее.

Начал слушать Ирину Левенец про управление ожиданяи в продуктовой разработке, послушал чуть-чуть рекламы, почувстоввал что не "прет" и решил, что если захочу послушать про управление ожиданиями и общение с заказчиками так почитаю\послушаю Сергея Бережного, так что убежал на круглый стол к Денису Бескову "Методики расчета эффективности системного аналитика". Денис - был некогда охарактеризован коллегой как "очень крутой чувак" при просмотре кого он там фолловит в френдфидике и характеристику свою подтвердил =).

Денис - руководитель отдела системных аналитиков в Касперском, и в подчинении у него что-то околj 40 человек, и проблема как же оценивать Аналитиков и показывать бизнесу, что они полезные люди и проектам помогают стоит вполне насущно)
Были предложены разные подходы и метрики, типа:
соотношения времени на работу  к календарному времени,
количество\качество генерируемых артефактов,
различные виды Peer(которое достаточно быстрое, т.к. "3 листа в день пишешь, а 5 листов в час -читаешь"(с) Мартыненко Сергей) и не очень peer-review,
оценка количества багов из-за некачественной аналитики(вроде бы у товарищей из Епама была в этом проблема, до 50% времена баг-фиксинга уходило на исправление ошибок из-за неправильной аналитики) и т.д.
Попутно обсудили:
что должен уметь аналитик: коммуницировать, строить процессы
всегда ли он нужен(т.к. 5 разработчиков делают проект на 15% быстрее быстрее, чем 7 разработчиков + пм + 4 тестера + 2 аналитика),
как проверить результыта его работы:
матрицы "Обьект \ Действие", "Судьект \ Действие" (по личному опыту Сергея позволяют выявить еще +80 требований к тем 16, что написал аналитик =)) и наличие требовний в виде тестов,в результате обсуждения последней темы, вобще дошли что надо писать тесты(типа спецификаций, а не юнит-тесты) а потом спецификации (везде ТДД проникает - даже в аналитику =)).

Где-то походу этих рассуждений дошли, что артефакты, время и т.д. - это все фигня, т.к. надо смаппить работу аналитика в профит\доход фирмы и понять окупается ли его использование в том или ином проекте, где-то к этому моменту закончилось время и проблему так до конца и не обсудили, хотя было очень интересно и хотелось еще)

Второй круглый стол вел Юрий Веденин "Оценнка рабоыт аналитика: качество через количество". Юрий в своей компании является аналитиком в предпродажном отделе, где они пишут Proposal`ы для тендеров, и у него тоже стоит задача объяснить руководству, что они пишут лучше пропоузалы, чем допустим производстенный отдел. Юрий оценил все свои пропозалы и создал некий чек-лист идеального пропоузала и выставил коэффициенты важности тех или иных пунктов и задался вопросом, а можно ли через этот чеклист оценить качество работы, если да - то соответствие чек-листу будет коррелировать с успешностью выигрывания тендеров, и профит от него есть. В начале дискусии посетила забавная мысль, что создание чек-листа попытка в аналитике создать некий аналог Definition of Done в ажайл-проектах.

В общем-то дискусия крутилась вокруг шаблонов\чек листов, и всего-такого, что они важны но не решают, т.к. противоречачищй чек-листу пропозал вполне может выиграть тендер:
Думали, как вобще оценить то, что аналитик производит:

• как оценить его коммуникации(читай умение извлечь информацию), 
• как оценить его возможность синтезировать решение проблемы(когда сам заказчик не может ее четко сформулировать). 
• Может ли аналитик быть полезен, если его все ненавидят. 
• Что отношения он строит с разными группами заинтересованных лиц: заказчик, пользователи, получатели ценности. 

И пользователи вполне могут не любить аналитика, за то что, он показывает насколько неэффективен\противоречив их процесс.
Интересную метрику предложила Наталья Желнова - количество "WTF от пользователей после выхода проекта".

На каком-то этапе мне показалось, что проект вошел в рекурсию относительно обсужденяи чек-листа и я пошел в первый зал послушать Сурову Ирину про сравнение форматов требований.

Мне было интересно, т.к. никогда особо не задумывался, что разные форматы - удобнее разным группам пользователей,  привык писать текстов - написал текстом, привык рисовать диаграммы - на том и остановился. Ирина же решила сравнить, что Действительно удобно коллегам\разработчикам\тестировщикам\пользователям и всем остальным, построила матрицу вида:
текст | таблица | картинки | диаграммы x Пользователи | Разработчики | Методология | Коллеги-Аналитики | и т.д. и нашла, что подходит ЕЙ в ее ситуации и компании. За обед рассказывали, что им мол было скушно, но меня всегда восхищает, что кто-то задумался над тем, что я например всегда делал по "привычке"\умолчанию.

Потом был обед, еда растворила  концентрацию кофе в крофи и почувствовал себя овощем, попробовал зайти на мастер -класс Ирины Векленко "Анализируй это: Жизнь как проект", но понял, что вобще не могу думать, а тока слушать и ретировался в основной зал к Сергею Мартыненко с вариантами управлениями требованиями(читай управление задачами),  были рассказаны про отвратительные плохие и хорошие методы.
Из нового (не знакомого до этого) выловил интересный метод: сначала неопределенные (по времени деланья) и критичные фичи (хз на сколько затянуться, но важно сделать), потом определенные и критичные(их знаем сколько сделаем в релиз), потом определенные и некритичные(после того как все критичное готово), и потом неопределенные некритичные - зафакапим и затянем сроки - "да и хрен с ними".

Потом был доклад Ильи Корнипаева по теме "Требования к ПО и использование творческих методов", Илья пересказывал тренинг какого-то известного чувака разработчика требований, который был на (после) Софтвейр Пипл, и вобщем-то все свелось к пересказу + разговорам, что я это не пробовал, но выглядит уже знакомым и не особо полезным. Что-то полезное и интересное записал, но доклад в целом выглядит слабо.

После пошел на мастер-класс Дмитрия Безуглого и Виктории Преображенской "Использование творческих методов в групповой работе", было весело и здорово, виктория в кратце рассказала про подход design thinking, это когда команда хирургов (психо)аналитиков собирается вместе и, задавая перекрестно клиенту вопросы, добивается от него понимания, что же ему на самом деле надо и какую его проблему решить)
После чего 15 минут попытали нашего подопытного, у кого была проблема переизбытка информации и пришли к выводу, что хочет он профессионального признания и внимания у девушек и потому то так много и читает.
И в идеале хотел бы получать важную и своевременную инфу прямо в мозг) Вроде получилось вполне правдо-подобно)

После было закрытие аукцион разрисованных участниками бокалов, и поздравление именниницы, которая приехала сюда в свое день рождения) После чего, часть людей отправились в Малинки, а часть отправилась обратно в Москву)

Отдых в Малинках. День второй.

После чего было афтер-пати, на котором повыяснялось, что с кем-то из Самарских мы были вместе на ажайлкемпе буквально за соседними столами) И еще было пиво, шашлык и прочее, что я достаточно смутно помню) Кто-то обсуждал насущные проблемы, люди делились опытом, инсайдами и всем-таким.

На второй день погуляли по Малинкам, позагорали, некоторые покатались на лошадях ближе к 11-12 все повыползали из домиков, и потянулись к беседке с флипчартом для круглых столов, первый круглый стол "Про игры для качества По" от Эдуарда Галиаскарова я все пытался не заснуть, т.к. как-то рано встал и на воздухе быстро расслабился, и все время клевал носом и делал дыхательные упражнение, чтоб совсем не упасть со скамейки, посему ничего путного не напишу.

После первого круглого стола подоспела первая партия шашлыка и силы пришли  ко мне) Во время всеобщего голосования решили обсуждать вопрос как же найти Хорошего Аналитика (рекрутерский вопрос для компаний видимо, как квартирный вопрос для людей =)). 

Дмитрий Безуглый рассказал, что же он ищет в хорошем аналитике, и свою градацию мастерства - RS(Requirement Specifier) - System Analysist - Business Analysis - Product Owner\Product Manager. В общем-то по большей части мне показалось, что эти качества схожи с теми, что нужны качественному пму: типа коммуникативности, многозадачности, организованности(так что идите почитайте Орлова, а то мне лень расписывать) ну и плюс интеллекта: вербального и визуального, а по остаточному пунктам идет знание системного анализа, и знание предметной области. Но в целом было полезно и приятно послушать. Да и Дима Безуглый сразу видно может, умеет и хочет рассказать полезно, приятно и интересно.
Эта тема захватила народ, и собственному всю оставшуюся часть дня, до того как я уехал в беседке обсуждали как интервьюировать, так чтоб не было безумно жалко потраченного времени, рассказывали и придумывали кейсы: как проверить те или иные качества.

Второй день мог бы быть подлинее и побольше.

Жалею, что как-то пропустил тот момент, когда большая часть народа рассосалась от беседки в разные стороны и я не пораздовал визитки, как завещал товарищ Орлов и товарищ  Дарси Резак. По моему кругу как-то восстанавливать по именам и списку участников, тех кого запомнил - неудобно)
Так, что  всем кому мое лицо кажется знакомым - зафрендить меня на моемкруге.

Психбольница и ты %username%!

Не далее, как в прошлые выходные осилил прочесть "Психбольница в руках пациентов" Алана  Купера. Замечательное чтиво по поводу простоты, сложности и создания именно того, что нужно пользователю.
Чтиво написано простым и понятным языком, и хотя Автор усиленно кроет программистов-пациентов (к коим и я себе причисляю) все равно оставляет неизгладимое впечатление собственного просветления.

Attention! Многа букав!

О чем же оно:
Понял, как жестоко я был не прав всю свою программерскую жизнь=)

Вкратце книгу можно бы  изложить так : за забором функций и ограничения реализации мы теряем из виду конечную цель производства самого продукта.

Для подтверждения хочется привести пример из книги:

Для нашего зациклившегося на функциях мира мысль, наверное, непривычная - вы не достигнете своих целей, используя набор функций как инструмент. Можно замечательно реализовать все функции из утвержденного набора и все равно попасть в беду. 

Для доказательства этого тезиса проектировщик взаимодействий Скотт Мак-Грегор на своих занятиях использует вот такой замечательный тест. Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет:
1) двигатель внутреннего сгорания;
2) четыре колеса с резиновыми покрышками;
3) трансмиссия, связывающая двигатель с ведущими колесами;
4) трансмиссия и Двигатель смонтированы на ходовой части;
5) рулевое колесо.

На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя:
6) быстро и легко срезает траву;
7) на этом удобно сидеть.
На основании пяти функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.

Читал и плакал! ;)

Плакаль

Уж настолько сильно книга пересекается с тем, что приходилось создавать самому или испытывать на собственной шкуре, как пользователю какого-нибудь доморощенного продукта.

Сам использую и зачастую создаю программное обеспечение с раздражающими интерфейсами (а ведь еще Скотт Беркун писал что раздражать людей - последнее дело).

Сам использую ПО, которое презираю - но приходиться терпеть, но т.к. я его использую для работы, смиряюсь и думаю, что так и должно быть и, что оно должно быть таким неудобным и мерзким.

Помимо казалось бы банальные советов не использовать неудобное ПО, которое вам не нравиться. Но его так же не следует Создавать, т.к. в итоге и оно выйдет боком, опять же процитирую:

Дороже разработки ПО обходится только разработка плохого ПО.
Программисты стоят дорого, а программисты, сидящие без дела в ожидании завершения проектирования, крайне раздражают руководителей.
Глупо же, думает руководитель, что программисты сидят и ждут, хотя могли бы программировать. Заставить программистов работать до завершения этапа проектирования - ложная экономия. Когда появляется программный код, процесс уже не остановить, поэтому проектировщики вынуждены реагировать на потребности программистов, а должно быть наоборот.
И вправду, глупо заставлять своих программистов ждать, а ведь очень просто сделать так, чтобы они не сидели без дела - надо, чтобы проектировщики взаимодействия планировали следующий продукт или релиз параллельно с созданием текущего продукта или релиза.

Ах, ну разве вам не знакомо: "Давайте еще одну фичу сделаем программисты\верстальщики\еще кто-то сидят без дела!". Так и хочется вот в этом месте передать привет, тем от кого я слышал эти фразы, но сдержусь)

Не только об интерфейсах:
Вот с чего бы юзабилисту рассуждать об архитектуре и дизайне ПО ? Ведь интерфейс - он от бизнес логики MVC отделен или еще как. Но нет и тему рефакторинга и переписывания заново затрагивают:

При каждом изменении программы - будь то исправление ошибок или добавление функций - появляются новые рубцы. Именно поэтому программы следует выбрасывать и полностью переписывать каждые пару десятков лет. Рубцовая ткань с течением времени становится настолько толстой, что препятствует нормальной работе.

Типичный представитель
 10 летнего ПО =) 

Читал и чувствовал боль и искреннее понимание.

Сейчас приходиться и в прошлом приходилось работать с 5-10 летними программными монстрами, которые имеют несколько слоев кода написанных в разных стилях, пару разных слоев абстракции Бд и ТЫСЯЧИ хаков, чтоб поддержать еще и вот эту логику.

Эдакий мясной рубцовый-мутант =)

То же самое относиться и к использованию прототипов в качестве основы для будущего по (ну жалко же выбрасывать!).
Только тут вы сразу начинаете с нежизнеспособного мутанта с 10ю поддерживающими его костылями.
Это кстати можно сказать обратная сторона ажайл-разработки, как только показана первая РАБОЧАЯ версия программы, выкинуть и переписать ее уже будет сложно.

Так что :

Скрытые издержки проекта по разработке программного обеспечения, даже при опытном руководстве, достаточно велики, чтобы даже Дональд Трамп задумался. Гонки на яхтах и пристрастие к наркотикам в долгосрочной перспективе обходятся дешевле, чем неконтролируемое создание программного обеспечения.

Все то, что я уже успел написать это одна двадцатая всех идей книги. Пока читал буквально разорвал ее на цитаты(честно-честно накопипастил себе десяток страниц цитат и мыслей )) 
Уж больно они точны и хороши. 

Лучший способ сделать программу дружелюбной к пользователя поставить на коробке штамп "USER FRIENDLY".
Зачастую в составляющей программы заинтересовано 3 стороны:
бизнес - "продукт овнер", тот кто заинтересован на ней навариться,
технари - "тестеры, бэкэндеры, фронтэндеры", те кто ее разрабатывают,
проектировщики\юзабелисты, те кто предоставляют голос пользователя.
Так вот для успешного продукта не достаточно только первых и вторых, такой продукт может продаваться и быть монополистом на рынке, но как только придет конкурент который позаботиться о пользователе, так и вашему продукту настанет крышка.


Как пример приводиться 3 компании: Novell, Microsoft & Apple.

• Novell -  была монополистом на рынке локальных сетей, но как только появилось чуть-менее геморройное  для настройки по и оборудование для локальных сетей она стухла и ушла с доминирующих позиций.
• Microsoft  - многие плюются на него но пользуются его продуктам, т.к. выбора - нет, но победить его пока не кому.
• Apple - какое-то время переживала феерический кризис, но из-за ориентации на интерфейс и пользователей выжила благодаря поддержки лояльных пользователей и теперь снова на коне.

Programmers VS Users

Красной линией по всей книге идет черта: позволять программистам проектировать софт - не правильно. 
Так как программист это Homo logicus, а не обычный Homo sapiens.

Мы - программисты отличаемся от обычных людей по 4 важным пунктам:

• Программисты пожертвуют простотой ради контроля. 
• Мы предпочтем более но сложную, но понятную систему магическому "черному" ящику.
• Для хомо логикус контроль - цель, тогда как сложность - просто цена, которую они готовы платить за достижение цели.
• Обменяют успех на понимание.
• Хомо логикус не может устоять перед тягой познания - он просто обязав узнать, как работают вещи. Хомо сапиенс же, напротив, стремится к достижению успеха.
• Программистам знакомо желание добиться успеха, но они часто принимают провал как цену, уплаченную за понимание.
• Они сосредотачиваются на исключительных ситуациях вместо того, чтобы сосредоточиться на типичных. 
• Нужно обработать и этот возможный вариант! (с) Я, более 1000 раз за всю свою жизнь
• И, наконец, ведут себя грубо и прямолинейно, как быки.

  

  Типичный программист

  
  

• Мы смотрим свысока на тех, кто не способен разобраться в этом не совсем интуитивном функционале: 
• Ну что за идиот! В мануале ж все написано!
• Кто смотрел Футураму ?) 
• Кому (из программистов) НЕ нравиться Бендер ?) 
• Всем нравиться! 
• Дык Бендер это сферический программист в вакууме!
• Логичный (робот же), приямолинейный (честый =)) и грубый =)

Подпишусь под каждым пунктом!


Итого: mustread!

Чтение такой не совсем профильной литературы раскрывает чакры и мозг в нужную сторону и помогает взглянуть на то, чем ты занимаешься с другой стороны. 

Ладно пожалуй хватит пересказывать книгу, должна же быть у вас мотивация прочитать ее. В добавок о том, о чем я уже рассказал в ней раскрываются еще такие темы, как:

• культура программирования 
• повторное использование кода, и почему это плохо
• как мотивировать разработчиков на создание простых и понятных для людей, но сложных в реализации интерфейсов.
• почему программист не может быть хорошим проектировщиком (подсказка: противоречие интересов, см. пункт выше)
• как сделать меньше, но лучше
• личные и корпоративные цели пользователей при работе с программой
• о тяжелой судьбе проектировщиков и факторе "это ж очевидно"
• о юзабелити-тестировании, итерациях, документации, общем словаре и всех-всех-всех ... 

А так же главные фичи книги, средство избавление от всех болезней, ответ на главный вопрос жизни, вселенной и всего такого, работающие практики: 

Целе-ориентированное проектирование и Персоны

Если вы вы слышали краем уха про agile-проектирование продуктов для пользователя, так вот все это копи-паста с ЭТОЙ книги. 

Удачного чтения и спасибо за рыбу!

Инженерные практики: Модель принятия инженерных решений Евгения Кривошеева

Дисклаймер:

Стас Фомин(http://belonesox.moikrug.ru/) регулярно негодует, что последствия конференций как-то не видны: т.к. первые два-3 дня видна отдача в виде отчетов а потом про них все забывают, и как-бы 5-6 отчетов\упоминаний не слишком выдающийся результат для такой огромной кучи усилий как собрать конференцию =)

Потому периодически пересматриваю и пытаюсь отписывать фидбэк)

Так вот вместо того. чтоб слать его лично ему, можно ж написать в блог и пользу от фидбэк`а получат больше чем 1-2 человека =)

Собственно присутствовал на самом докладе (да он настолько хорош, что хочется повторно увидеть), но т.к. где-то только с середины решил пересмотреть (я там где-то даже на 30-й минуте в кадр попал =)).

Полезная часть: =)

Небольшой предварительный список вопросов:

- Я могу сказать - почему у меня столько классов сколько их сейчас ?

- Я могу сказать - что для меня важнее гибкость или просто кода ?

- Я могу сказать - зачем я применяю\не применяю определенный паттерн в данном месте ?

- Я могу сказать - чем обоснована моя стратегия деплоя релизов на продакшен ?

- У меня (в моей компании) знают, что такое architectural guidelane и они есть ?

И т.д., если хоть на один вопрос вы ответили - "нет", то видео надо обязательно посмотреть.

Собственно ссылки на само видео презентации Евгений Кривошеева "Модель Принятия Инженерных решений": ekr's blog: Бухтелово на AgileDays2011 или http://vimeo.com/22162357.

Докладчик говорит вполне живо и бодро потому: максимальное ускорение при просмотре можно выставлять на уровне 1.3х =)

Рассказывает вроде бы и очевидные вещи, которые всем нам (ну точнее всем, кто учился на инженера) преподавали еще в институте: "Сначала думай, а потом делай", и если ты не можешь сказать ПОЧЕМУ ты так сделал и ПОЧЕМУ оно будет работать - то это не инженерное решений (по-моему доказательство и сдача лаб по схемотехнике, это до сих пор самое сложное, что мне приходилось делать за всю свою жизнь, как инженеру =)) .

А в процессе работы все , как всегда сводиться к: "По привычке (из-за лени) сделал, как в прошлый раз, потому, что мозг так натренировался."

Это надо исправлять и не в последнюю очередь смотря такие доклады и просто немножко включая голову при проектировании.

Потому смотреть и запоминать, а через месяц проверить прижилось ли в голове и посмотреть еще раз, и повторять до тех пор пока не приживется!

Тем кому понравилась презентация рекомендую посмотреть еще и видео Архитектура в Agile — переосмысляя идею модульности и компонентности (Андрей Бибичев, AgileDays-2011), про ажайл там ан самом деле ровным счетом ничего =) Но излагаются хорошие инженерные практики и стремление думать головой, а не спинным мозгом.

Послесловие:

Вообще удивительная вещь доклады и конференции: вроде бы рассказывают очевидные вещи, но ты все равно так не делаешь\не задумываешься о том, как делаешь до тех пор пока не ткнут носом.

А на конференцию по ажайлу можно ходить даже вы этот ажайл на дух не переносите хорошие инженерные практики (о которых конференция чуть ли не на 50%) полезные в любой методологии.