Бхагават-гита 18-43.

“В век Кали все рождаются шудрами “

Шримад Бхагаватам 12-48.

История

Лидерство с древних времён понималось как набор неких качеств, а именно – харизма, интеллект, решительность, etc.  А под лидером понимался соответственно тот, кто этим набором качеств обладает. Так говорилось в ведах/упанишадах, так говорил Аристотель, так говорили все вплоть до середины 20го века. А потом стали плодится тренинги личностного роста что-то случилось и лидерство разделилось: оно как бы осталось набором качеств, но оно так же стало и процессом. Внезапно лидеру уже не обязательно было обладать какими-то там качествами, а достаточно стало вести кого-то куда-то.

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

«Все искусство управления сводится к двум вещам: одарять и карать»

Магомет II (13й, чтоб вы понимали, век)

Как только лидерство стало набором инструментов, под это дело начала развиваться теоретическая база – стали плодится теории лидерства одна краше другой. Группы поведенческих теорий, стилевая теория, ситуационные теории,  объектно-ориентированная функциональная теория. И хоть они такие разные, есть в них и кое-что общее – они путаются в показаниях употребляют слова leader и manager как синонимы. Есть в этом что-то такое, да?

Однако прошло время и ни одна теория не воспитала ни одного лидера тренд в проработке теорий сместился с инструментов (т.е. менеджерской части лидерства) на таки (внезапно!) качества (эмоциональный интеллект, харизму, интуицию и т.п.). С чего бы это?

Текущая ситуация

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

• если слышно, что-то вроде “мы так делаем, потому что так сказал ХХХ. В смысле «пробовали ли спорить»?!?” – можно с уверенностью заключить, что у ХХХ таки прокачана харизма (или дуболомство и спорить чревато).
• если же слышно, “мы так делаем, потом что так делает ХХХ. Делать по-другому? нееее  - ХХХ знает, что делает!“, то тут мы имеем дело с прокачанным авторитетом, который был не раз подтверждён практикой.
• “он нас провёл через сложную ситуацию, но паники не было, все знали что делать и как” – пример того, как отличные менеджерские скилы сослужили службу ХХХ’у и организации.
• “мы вас научим быть лидером за N занятий и люди пойдут за вами” – речь на самом деле про микс из самых обычных менеджерских практик типа делегирования, советов КО типа “берите на себя ответсвенность”, банальных манипуляций и немножко психологической помощи. Эти штуки могут улучшить ваш менеджерский левел, вашу самооценку, но не сделают вас лидером.

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

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

И вообще – действия направленные на то, чтобы сподвигнуть других людей на что-то… это манипуляция. Никому не нравится, когда ими манипулируют. Но люди верят искренности, когда человек никого не заставляет, не стимулирует… а просто делает. И, как бы парадоксально это не звучало, отсутствие стимуляции мотивирует. Мне лично очень близка позиция Джона Холта:

«Лидер – это вовсе не человек, с огромной толпой последователей, как это представляет себе большинство. Лидер – это человек, который идёт своим путём не прилагая усилий по привлечению последователей; он даже не интересуется, есть ли у него эти фоловеры. “Лидерские качества” – это не те качества, которые позволяют человеку привлекать последователей, а те, которые позволяют ему справляться с делом без последователей. Эти качества, как минимум, включают в себя смелость, настойчивость, спокойствие, юмор, гибкость,  находчивость, решимость, острое чувство реальности и способность сохранять спокойную и ясную голову даже в неприятных ситуациях. Это противоположность той пресловутой “харизме”, о которой мы слышим так часто.»

Джон  Холт

Вот такая настоящесть встречается достаточно редко. Скорее всего потому, что такое лидерство проявляется не на заказ, а только там, где это интересно самому лидеру.

Эта позиция очень перекликается со здоровым нарциссистическим лидерством.

Выводы

• Кшатриев не найти, лидеры уже не торты :)
• Когда говорят про лидерство, то надо уточнить, о чём же таки говорят.
• Когда говорят про лидерство в контексте обучения ему, то мне делается смешно.

Домашнее чтение

• Лидерство – история, теории, стили… достаточно для входа в тему;
• История вопроса в хронологическом порядке;
• Кастрированная версия для ленивых на русском - Обзор теорий лидерства;
• Narcissistic leadership - что-то похожее на лидерство в моём понимании;
• Если всё-таки кто-то мне не верит, и хочет научиться быть лидером, то вот годная школа лидерства. ггг.
• Если всё-таки кто-то и правда хочет научиться быть лидером, то надо будет пахать: THE U.S. ARMY’S 11 LEADERSHIP PRINCIPLES.

P.S.:

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

Самая любимая:

«Самый хороший лидер тот, о существовании которого люди просто знают. Не такой хороший лидер тот, кому люди покоряются. Хуже тот лидер, которого люди презирают. А при хорошем лидере, который мало говорит, когда его работа сделана и его цель достигнута, люди говорят: «Мы сделали это сами»

Лао-Цзы

Случайно заметил: авторы Пруткова плагиатили или у дураков мысли сходятся?

«Если умело держать вожжи, лошади побегут сами»

Конфуций

«Хорошего правителя справедливо уподобляют кучеру»

Козьма Прутков

Пара замечаний к вопросу о возможности научить быть лидером:

«Вы можете вытащить парня из деревни, но вытащить деревню из парня никому не под силу»

американская поговорка

Спрашивать: «Кто должен быть боссом?» — все равно, что спрашивать: «Кто должен быть тенором в этом квартете?»

Конечно, тот, кто может петь тенором.

Генри Форд

Просто интересная мысль (эдакий перефраз теории пассионарности):

Есть два типа естественных вождей: первый переполнен энергией, активен, любого перекричит, задавит, собьет с толку и потащит за собой хоть бы и против воли; второй молчалив и на первый взгляд малоподвижен, но покоряет толпу ощущением спокойной, уверенной силы. Сила вождей этого склада, утверждал умнейший Иван Фердинандович, загадочно посверкивая на учениц стеклышками пенсне, состоит в природном психологическом дефекте – им неведом страх смерти. Наоборот, всем своим поведением они как бы искушают, призывают небытие: мол, приди, возьми меня скорей.

Борис Акунин. Любовница Смерти

P.P.S.:

Танаха, тут есть то, что ты хотела.

P.P.P.S.:

problem? :)

Вступление

Любой, кто следит за нашей тусовкой (а я, кстати, рекомендую следить – появляются новые лица), уже должен был понять: пошли собеседования, разочарования и… COTOHA не выдержит и напишет что-нибудь иронически-саркастическое на эту тему. Пишу. И да – любой, прошедший отбор и оставивший тут комментарий, получит лишний “+” при прохождении испытательного.

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

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

Предупреждаю ещё раз: статья интересна теоретически, но малоприменима  практически (и я ниже напишу почему).

Зачем нам собеседование?

Рассмотрим немного мотивации, цену вопроса и стратегии проведения собеседования с точки зрения компании и кандидата:

Для компании

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

Для кандидата

Кандидату собеседование необходимо, чтоб продемонстрировать свои хорошие стороны и таким образом оказаться тем самым, кто вакансию заместит. Цена вопроса для кандидата в общем случае не такая уж и высокая – если тебя возьмут по ошибке, то ты какое-то время просто по-получаешь некую ЗП, некие знания и некий опыт, а потом вернёшься к тому, откуда начинал (к поиску работы). Но, в принципе, ты в выйгрыше. Соответственно имеем стратегию: постараться показать, что ты достоин вакансии всеми возможными способами, с тем, чтобы уверить компанию в правильности выбора.

Налицо конфликт интересов

Как ни крути, а цели у “собеседников” разные. Поэтому компании читают всякие советы как найти профессионалов, а соискатели штудируют книжки типа “Легкий способ пройти собеседование при приеме на работу. Все вопросы и ответы” и старательно мимикрируют. А рекрутёры им в этом помогают. Так-то!

С учётом того, что компании хотят найти не просто “того самого” кандидата, но и сделать это в кратчайший срок (т.к. срок этот, как обычно, горит), то компании регулярно лажаются и ещё больше усложняют себе жизнь. Про это традиционно распинается Cartmendum (aka Макс Дорофеев) в своих докладах про Персики и Лимоны. Основной причиной лажания компаний является то, что оценить “качество” соискателя за короткий срок (читай – за собеседование) достаточно сложно. Что же делать? Вот тут самое время объяснить при чём тут пол…

Метафора

Собственно, имеем ситуацию: с одной стороны есть компания, которая должна за короткий срок выбрать себе самого качественного кандидата среди множества соискателей, с тем, чтобы обеспечить максимальное качество своих будущих проектов, а с другой – множество соискателей, которые пытаются всеми силами показать, что они качественные. Соискатели ничем не рискуют, компания рискует качеством будущих проектов. Ничего не напоминает? Предлагаю в качестве эксперимента заменить слова “компания”, “соискатели” и “проекты” на “самка”, “самцы” и “потомство” соответственно. Что видим? Видим метафору – процесс найма и отбраковки сотрудников сравнивается с половым отбором. Не спешите смеяться – метафора получилась даже глубже, чем я сам предполагал, но об этом ниже…

Компании выбирают себе работников, чтобы совместно сотворить проекты, так же, как и самки подбирают самцов, чтобы совместно сотворить потомство.

Немного теории

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

Аналогия #1:

Эволюционно-стабильные стратегии поведения самок и компаний совпадают – как первые, так и вторые стараются тщательно отобрать самцов (профессионалов) с тем, чтобы получить максимально качественное потомство (проекты).

Как в дикой природе происходит этот отбор? Предоставим слово компетентным людям:

Какого самца выбрать на роль отца своих детей? Хорошо бы, чтобы он помогал самке заботиться о потомстве. Однако в норме (если речь не идет о страусах, людях и еще нескольких видов животных) самец не вкладывает в детей ничего, кроме сперматозоидов, и самкам на помощь рассчитывать не приходится. Но, несмотря на это, самки активно выбирают самцов — предпочитают одних и отказывают другим. Что же и зачем они выбирают?

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

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

Как видим, у самок те же проблемы, что и у компаний :)

Аналогия #2:

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

Однако самки, в отличии от компаний, лажаются достаточно редко. Почему? Потому что самки знают на что смотреть, то есть они научились вычислять “честные” признаки качества. Те же компетентные люди объясняют глубокую мысль про принцип гандикапа:

В 1975 году Амоц Захави (Amotz Zahavi) сформулировал концепцию гандикапа, согласно которой информацию о качестве генома самца могут нести лишь вредные для выживаемости признаки. Так, размер хвоста павлина является мерой качества его генома, поскольку с длинным хвостом сложно улетать от хищников и только очень высоко приспособленный самец (с хорошими генами) сможет с большим хвостом дожить до момента размножения. Точно так же яркая окраска оперения и громкие песни самцов птиц делают их более заметными для хищников.

Таким образом на основе этой метафоры имеем:

критерий качества профессионала обязательно будет “честным”, только в том случае, если он профессионалу мешает быть профессионалом. такие дела, да.

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

А вот нечто, что требует от него “непрофессионального” поведения – это так просто не подделаешь. Что же может выступать аналогом “длинного хвоста” у профессионала-айтишника?

Длинный хвост, яркая раскраска и рога у айтишников…

Нас интересует некая деятельность, которая будучи профильной (айтишной) при этом не является профессиональной. Из определения “профессинальной” деятельности следует, что за неё платят денег. Отсюда деятельность профильная, но не профессиональная – та, что делается по теме, но безд-возд-мезд-до, то есть, даром (с)

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

Теперь собственно список: думать долго не надо – он очевиден. Привожу его в порядке убывания “длины” признака*:

1. Участие в работе локальных юзер-груп типа JUG, PHPUG, FPUG, etc. Выступает там – хорошо, руководит – ещё лучше :)
   Это рога – на таких встречах можно бодаться :)
   Важно: участие должно быть регулярным. Если кто-то просто числится, то это не то…
2. Open Source проект. Мейнтейнит – хорошо, в день (для девушек – в месяц), когда родился ребёнок, зафиксирован комит на GitHub‘е -  герой!!!
   Это хвост – он тянется за разработчиком :)
   Важно: проект должен быть оригинальным (что-то типа “первый DI-framework для PHP” гораздо лучше, чем “очередной CMS”);
3. Выступления на всяких tech-talk’ах и т.д. Выступает – хорошо, хорошо выступает (а это, вообще, видно по презентациям на slideshare или scribd) – лучше.
   Это громкое пение – оно выдаёт разработчика хищникам эйчарам и прочим тролям :)
   Важно: заезженные темы не канают. Кроме того не канают всякие евангелистические штуки типа “_что_ надо делать для всеобщего счастья”. Конкретика типа “_как_ настроить счастье CI-сервер в отдельно взятом проекте” ценится гораздо больше.
4. Блог или форум технологической тематики. Пишет – молодец, пишет часто – ещё лучше. Пишет что-то оригинальное (например про свой опен-сорс проект :)) – вообще герой.
   Это яркая окраска – также служит для выделения :)
   Важно: посты должны быть реально оригинальными и профильными. Рассуждения о политике на техническом блоге ни о чём не говорят (ну кроме как о политической ориентации автора). Ещё я не определился с переводами – насколько это оригинально я хз. Склоняюсь к тому, что дело нужное, хоть котируется и меньше, чем полностью авторские посты.

* DISCLAIMER: порядок длин определён исходя из моего личного понимания вопроса. Готов спорить :) Также готов выслушать дополнения.

…которые для самок компаний бесполезны

Ну вот примерно тут вы уже и поняли, почему я сказал в начале, что статья – бесполезняк, да? А бесполезняк она потому, что вероятность встретить на собеседовании таких, как тут описано рогатых, хвостатых и яркоокрашеных половозрелых самцов специалистов, примерно равна вероятности встретить в живой природе таких птиц как Сирин, Алконост или Гамаюн. Именно поэтому Джоэл Спольски пишет, что такие специалисты на рынке труда не появляются, и регулярно совершает набеги на ведущие технологические университеты США и увозит в плен девственниц лучших студентов на практику. Ему это помогает, т.к. у него довольно скромные (в количественном плане) потребности… А что делать всем остальным?

…и которые полезны

Остальным надо ловить самцов ещё до полового профессионального созревания и надеяться на то, что их будущие перья будут яркими, рога большими, хвост длинным, а голос громким. Чтобы не было мучительно стыдно за бесцельно проведенные собеседования, советую обращать внимание на некие признаки, которые коррелируют с последующими успехами на профессиональном поприще. Напоминаю, что соискатель – чаще всего студент (4й или 5й курс), учился чаще всего в наших ВУЗах, опыта работы чаще всего нет. Вот, собственно, эти признаки:

1. Имеет что ответить на вопрос “что-нибудь для себя (кроме лаб и курсовиков) писал?”. Это, я считаю, самый важный признак – человеку таки нравится быть программистом.
   Важно: надо не забыть на радостях поглядеть на творение или хотя бы поузнавать деталей;
2. Знает что такое local user groups, пару раз там бывал – хорошо. Очень похоже, что технологию соискатель выбрал себе сам, а не просто “все на .NET и я на .NET”;
3. Рассматривал код какого-нибудь опен-сорс проекта и может что-то про это рассказать. Тоже хороший признак. А ещё это значит, что соискатель знает, что такое системы контроля версий, и как минимум умеет чекаутить :)
   Важно: тут неплохо бы открыть сразу код и попросить показать понравившиеся места;
4. На вопрос “что делал на выходных?” отвечает “Да вот поковырял Go…” Ну или haXe или что там у нас новенького и интересненького?
   Важно:  нужно чтобы кто-то из собеседующих был в состоянии поддержать беседу по этой интересной теме и мог понять насколько “поковырял” пошло дальше чтения статьи (статья, кстати, годная да и каменты доставляют). Если дальше чтения не пошло, то плохо, что врёт, но хорошо, что читает статьи :)
5. Читает блог одного из собеседующих. Как это никто из собеседующих не ведёт блог?!? Ну тогда хотя бы читает один из блогов, которые читает кто-то из собеседующих. Шутки-шутками, но где ещё узнавать новости своей любимой технологии как не на блогах её создателей или апологетов?
   Важно: на слово не верить :)
6. Средний бал стремится к 5. Это свидетельствует о том, что человек способен или а) “решать вопросы” или б) делать скучную работу (подумать только – получить 5 по БЖД по-чеснаку!) – и то и то хорошо, но второе, конечно же, лучше.
   Важно: выяснить а), всё-таки, или б).

Ага. Чуть не забыл про ещё один архиважный признак:

• Компания должна уметь и быть готова учить сотрудника, а также стимулировать и поддерживать его самообучение, т.к. если пустить дело на самотёк, то красивые рога, перья и хвосты эта компания будет видеть только на упомянутых выше картинах Васнецова.  Так-то!
  Про это будет отдельная псевдонаучная вдумчивая статья.

и ещё пара замечаний

Кроме того есть пара моментов, которые резко “утускняют” ярую раскраску, портят вид красивых рогов и лохматят хвост:

• активный аккаунт на вконтакте или одноклассниках (вероятно, это мозговые паразиты);
• туева хуча постов на всяких форумах (особенно если эти посты – попытки доказать, что в интернете кто-то не прав);
• (ох, чую будет срач, но тем не менее) на сайтах типа StackOverflow.com куча ответов на нубские вопросы. Я не имею ничего против дельных ответов на сложные вопросы, но разражает вот что-то типа такого. Причём раздражают не те, кто спрашивает, а те, кто отвечают… И да – про это тоже будет отдельный пост :)

Прочии аналогии

Я выше говорил, что метафора оказалась глубже, чем она мне показалась сначала, и обещал ниже это показать. Это уже почти самый низ, так что показываю:

Аналогия #3:

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

Аналогия #4:

С развитием homo-sapience, кроме исключительно генов, стал цениться ещё и характер, а именно желание заботится о потомстве. Именно поэтому для кратковременных связей самки предпочитают самцов маскулинного типа, а для создания семьи (читай – воспитания потомства) -фемининные. Стоит ли говорить, что любая компания понимает, какие именно программисты нужны для старта проекта, а какие для поддержки.

Аналогия #5:

Когда самка не может выбирать самца… то она выбирает потомство (так называемый “скрытый выбор самки/Cryptic Female Choice” – почитайте-почитайте, вы офигеете :)). По тем же самым причинам компании в зависимости от “качества”  персонала, может решиться работать над небольшим количеством сложных и больших проектов, или же над кучей простых и маленьких.

Выводы

Итак, что же делать, чтобы ваше потомство проекты получились наиболее успешными?

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

Для соискателей – надо отращивать “длинные хвосты”.

PS aka Домашнее чтение

• Принцип гандикапа – английская версия, более полная.
• Как правильно выбрать партнера (полезные советы для девушек) и, как выясняется, для компаний.
• Eсли нельзя выбирать самцов, выбирают детей – про “скрытый выбор самок” или что делать, если на безрыбье только раки :)

Предистория

Долго думал ехать или не ехать… Что? Картмендум будет? А ну мать его так! Поеду.

История

Сама организация ивента была на высоте, особенно конфеты с черносливом :) Как сечас принято, было 2 потока и я бегал туда-сюда. Ниже мои личные ощущения от докладов, которые я посетил:

1. Ловушки статистического планирования. Меньше от Дорофеева я и не ждал: как обычно рисованные слайды (теперь уже не просто так, а со спецэффектами а-ля стар-варз), формулы, и лёгкий намёк на то, что слушатели идиоты :). Шутка удалась: зал 2 раза купился, но в 3й раз уже не повёлся на провокацию. Вобщем 4+. Кстати, тут он просил его распознать – я распознал, застал врасплох и напугал штрафом. Он прикольный в замешательстве :) Кстати№2, на фотке он упитаннее – видимо недавний ремонт его подизмотал.
2. Нематериальная мотивация сотрудников: сумасшедшие идеи, которые работают. Такое чувство, что меня обманули. Выглядело это примерно так: “ведь все же читают мой сайт? все? ну так вот я вам как раз и перескажу, что там написано”. Ничего нового (даже анекдоты бородатые), за исключением одной фамилии – Орлов вскользь упомянул про великого педагога – Шаталова. За что ему большое спасибо. А взагали 3-.
3. Почему из ИТ-шников получаются плохие руководители, или основные проблемы с которыми сталкиваются ИТ специалисты. Отличнейший доклад. Информация, естественно, подана не новая, но она была предварительно адаптирована для недолгого доклада (например упрощена шкала:  в оригинале она от -1 до 7, в докладе от 1 до 9, вроде мелочь, а если б не это, то времени могло бы и не хватить), подана правильно, проанализирована, выводы сделаны. Мне показалось, что цель доклада была достигнута. Твёрдая 5. Единтвенный минус – начало доклада с примером мега проекта. Кагбе неясно какое отношение пример имеет к докаду, но с примером, как оказалось Дмитрия подставил Орлов :)
4. Компании-разработчики ПО: светлая и тёмная сторона. Один из немногих докладов, который являл собой новое в чистом виде. То, что там рассказали, нельзя найти ни в одной книге или статье. Юля и Тимур провели интересную аналитическую работу и выводы получили интересные. Но без ложки дёгтя никак нельзя: цель доклада была сформулирована невнятно (подозреваю, потому что их на самом деле было две), и как следствие не достигнута. Народ не понял, что их вызывали на диалог, а открытый конец доклада воспринял как “эээ… и что?“. А я понял, потому всё равно 4+ :)
5. Ситуационное лидерство или почему командами по разработке ПО нельзя управлять. Просматривая твиттер по пмлабсам до этого удивлялся заметками типа “на заснуть бы…” На этом докладе сам где-то так и натвитил :) Доклад – простой пересказ теории, ни примеров, ни живости. За всё про всё 3. Правда Дмитрий Башакин извинился, что первоначально доклад планировался 2х часовым, а потом внезапно он сократился до 45ти мину. Очень надеюсь, что именно это и стало причиной неудачи.
6. Динамика развития отношений в команде разработчиков. А тут наоборот. Если кто и хотел спать, то Игорь Лужанский их разбудил и дал заряд бодрости. Вообще к концу доклада моя белая зависть к докладчику начала переростать в чёрную: очень уж редко можно увидеть айтишника, но при этом ярко выраженного экстраверта (внимание!) аудио-видео-кинеститека. Вместо того, как обычно делает айтишник (а обычно этот интраверт-кинестетик тискает бумажку\пульт\микрофон и монотонно бубнит доклад), этот человечеще выбросил микрофон и говорил живым голосом, искал в зале глаза (складывалось впечатление, что он физически не мог опустить взгяд больше чем на полсекунды) и махал руками. Короче живое опровержение доклада Дмтрия Безуглого :) Я уж начал думать, это что человек с явной доминантой правого полушария и вообще в айти случайно… Но доклад! Доклад же 100% для роботов-левополушарников – всё разложено по полочкам: для каждого этапа дана вводная, определение, пример, необходимые действия, вывод! Ааааа!!! У него или 2 мозга или хирургически удалена перегородка между полушариями :) И да: 5.
7. Нетехническое собеседование для программиста. Очень полезный взгляд на собеседование со стороны “нормального” человека. Надеюсь, что суровые ПМы поняли, что надо немножко меняться. Вика дала много “фичечек“* непрямой и невербальной комуникации, однако, если Дмитрий Безуглый говорил правду, то эти семена доброго и вечного могли упасть не на ту почву, так как “у айтишников не то чтобы плохо с этим… они просто не знают, что это вообще есть” © Тем не менее 4+. И чувстуется, что гонка вооруженийзарплат всех достала, а сеньёр-ява-девелоперы ещё больше :)
   * я так понял, что фичечка это испорченная жизнью в айти фишка.
8. Летаргический сон проектного менеджера или Agile – это по-другому. Лёша и Наталья заявили в раздатке тему, которая по моим прикидкам могла бы быть раскрыта часа за 2 минимум. А начали они с того, что “у нас 37минут”. Как бы тут я начал подозревать. Начали они размерено, настолько, что я постоянно смотрел на часы и думал “как же они надеються успеть?” В итоге, когда доклад был окончен, то его содержание не соответсвовало названию, а название желаемому месседжу.
   Но было и хорошее – например, порадовала командная работа докладчиков, рисование в 4 руки и 2 флипчарта, репризы вопрос-ответ, etc. Вот… а народ откровенно скучал.  3+.
   Теперь самое главное :) Леша, Наташа, вы наверное сами не поняли, но продемонстрировали как бы самую суть агайла: командную работу и… готовность к выкатке в любой момент. Доклад можно было обрывать в любой момент (ну не считаю пафосной вводной) и получать более-менее законченную сущьность. Вобщем он так и был оборван: видно было, что попытались скомкать в 35 минут что-то большое, но не получилось. Вам бы ещё пару десятков минутспринтов на “доводку”…

Были ещё две флипчарт-сессии:

1. Эффективность работы: Проектная мотивация, приверженность участников проекта – Александр попытался донести здравые идеи, но испытывал небольшие трудности с их выражением. Но чувствовалось, что сам он темой болеет и ему это близко. Недостатком доклада было то, что было озвучено ЧТО должно быть, но не КАК этого добиться.
2. Модель поведения DiSC – просто супер. Кирил рассказал всё внятно, по делу, с примерами. Мне стало интересно, а было бы так же классно, если бы это был полноценный доклад?..

Выводы

Хочется немного поанализировать конференцию как таковую.

Какие цели могут и должны преследовать участники?

• Начинающий или собирающийся стать менеджером может получить много информации, которую ему лениво читать в книгах или википедии. Компактно и за 1 день. Профит на лицо.
• Более-менее образованный менеджер не может преследовать цель “поучиться”. Это не получится – аналитики в докладах исчезающе мало. Как максимум вы в очередной раз структурируете (в лучшем случае) свои знания. Но чудеса бывают. Тут профит сомнительный.
• Если цель – потусить, то всё чудесно. Участник может потусить :) Докладчик может потусить ещё лучше.
• Сеять светлое, доброе и вечное можно, если ты докладчик. И при условии, что не все приехали потусить.
• Если вам на работе некогда поговорить с интересным человеком, то имеет смысл взять его с собой на конференцию. Это работает.

Что можно улучшить в организации?

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

Послесловие

Чувства смешанные. Что поехал – однозначно не жалею. С одной стороны обидно, что могло быть лучше, но с другой стороны, я же большего и не ждал :) Крепко задумался над неизбитой темой для доклада. Пока не могу придумать – ведь, блин, всё избито…

P.S.: По дороге туда играли с Настей в дурака. Именно что в дурака и как-то даже без вариантов получилось. Из достижений могу вспомнить только то, что я сливался вчистую весь вечер, но 2 раза повесил ей погоны.

Зато по дороге обратно играли сначала в дуру (гы-гы), а потом в чешскую дуру. Так то!

P.P.S.: кто-то за конфетами обращается?

Вдогонку к обсуждениям принципиальной возможности “win-win” (Развенчивание мифов о том как стать успешным (где-то глубоко в каментах) и Win-win, бывает ли он вообще?) на блоге об IT-бизнесе, где я отстаивал точку зрения о том, что “win-win” – это не более, чем красивая сказка, которой действительно выигравшая сторона прикрывает факт поражения проигравшей, начал читать книгу. И, собственно, уже заканчиваю, чего и вам всем настоятельно желаю.

Книга называется “Сначала скажите “Нет” (Оригинальное название “Start with “No”), автор – Джим Капм (Jim Camp), вроде как самый лучший в америке тренер по переговорам. Читать однозначно всем рекомендую, тем более, что там всего-то 80 страниц, а слог лёгкий.

А кому понравится, те, наверное, захотят глянуть на продолжение: “No: The Only Negotiating System You Need for Work and Home” – развитие темы, написанное через 5 лет, после “Start with No”.

Ну и да – люблю читать книги, которые внятно формулируют мои мысли. Приятно, чёрт побери :)

Ага, ну и к чему это я? Вот что пишет автор:

…я начал оспаривать модель “выиграть-выиграть” потому, что быстро понял, как часто она на самом деле подразумевает ситуацию “выиграть-проиграть”. Не стоит заблуждаться на этот счет: как ни печально, но, возможно, сделка в соответствии с подходом “выиграть-выиграть” заключается каждую минуту. Все обещания этого подхода – лишь манипуляции и лицемерие.

А вот что писал я:

классический “win-win” – это просто красивая сказка. просто, если преподносить ситуацию как “win-lose”, то сторона, которая “lose” может начать действовать неадекватно (от банальных обид и саботажа до приноса УЗИ в офис), поэтому все разрешения конфликтов, каг-бе, надо маскировать в обоюдовыгодное решение…

Вот. Ну и чтобы не сложилось впечатление, что 2 фанатика нашли друг-друга, то нет – я не считаю, что ситуация “win-win” невозможна в принципе, но на стороже быть надо. Слово Джиму:

Ну, конечно же, “выиграть-выиграть” звучит здорово! Именно поэтому этот подход настолько опасен, и именно поэтому вы должны быть очень осторожны. Если вы ведете переговоры через забор с соседом о том, когда пора начинать готовить угли для общего барбекю, подход “выиграть-выиграть” может сослужить вам хорошую службу. Но в схватке с жесткими, закаленными мастерами переговоров в реальном деловом мире нужно другое оружие.

P.S.: и на закуску… под катом :)

Решили мы помочь студентам ИНЖЕКа (aka ХНЭУ) понять чего от программиста хочет реальность. Сделать это было решено в виде код-ревью их курсовых проектов и написания разгромных соответствующих отзывов. Что и было сделано где-то в мае-июле. Я уже и думать про это забыл…

История

Но вот подходит ко мне Таня (наш главный по работе с ВУЗами) 26го сентября (в пятницу) и происходит у нас разговор:

Т: Привет! Помнишь мы в июне рецензировали курсовые проекты из Инжека…
Я: (чуя неладное) Было дело… 
Т: …и договаривались, что прочитаем им пару лекций о том, что у них не так. Время лекции пришло. Я сегодня об этом говорила с Витьком. предположительно это будет в самом начале октября
Я: (автоматически) я про лекцию ничего не помню. (сам лихорадочно пытаюсь вспомнить)
Т: на лекциях мы обещали объяснить студентам, что не устраивает  нас в качестве выполнения курсовых проектов
Я: (всё ещё надеюсь отмазаться) не помню :)
Т: это будет сборный поток, от 20 до 40 человек
Я: (до меня доходит, что я и правда ничего не помню) о госпади. ваще ничё не помню 
Т: будешь на 8 этаже, зайди – вспомним вместе
Я: ага. так и сколько у меня ещё времени?
Т: та! ещё куча – до начала октября…
Я: ok. (ну, думаю, до начала октября-то я успею подготовиться)

Сижу себе работаю… вдруг чё-то пробивает мысль: а какое сегодня число-то? Глядь в угол экрана, а там 26 сентября, пятница. Давай звонить Тане:

Я: Тань, так а это… когда точно лекция? А то сёдня уже почти октябрь…
Т: 29-го в 15:20. Это понедельник.
Я: так сёдня ж 26-е…
Т: ну да. А я как сказала?

Вот так и живём :) Лекцию мне, кстати, читать даже понравилось. Кому интересно, конспект можно почитать тут:
Programmers’ Mistakes for Dummies (файл)
Программистские ошибки для чайников (онлайн, с обсуждением)

P.S.: если выложу куда-то онлайн для обсуждения, маякну :)
P.P.S.: выложил на ДОУ. маякую :)

К чему это я? А вот прислали картинку (ещё 13го сентября) и навеяла она мысли… а сегодня (о блин, уже вчера!) пришёл проект от сейлов с офигенно понятным скоупом, и я про неё вспомнил. Когда этот пост задумывался, причина была более веской лично для меня, сейчас уже нет – я проекты пока не веду. Но написать, чувствую, всё равно стоит – может _того_ менеджера успокою :) ну типа присказка закончилась, началась сказка…

Наверное самая распространённая ошибка руководящего состава – искренне верить, что из говна можно вылепить конфету. Ошибка не в том, что конфету нельзя вылепить… ошибка в том, что нельзя надеяться при этом, что конфета будет вкусная.

Итак вот возьмём ситуацию, когда у вас есть проект с:

1. неопытными разработчиками (коты);
2. плохими требованиями (топор);
3. невозможностью его не делать и что-либо менять (дверь закроется и проект превращается в закрытую систему).

Знакомо?

Непременно удивляет уверенность высшего руководства, что в таких условиях менеджер может “не делать глупостей”. А что ему ещё остаётся, такому одинокому в этой закрытой комнате?!?

Более того, плохие требования даже с хорошими разработчиками заканчиваются “кровью” – разработчики, которых всё задрало, бодро уходят в неизвестном направлении…

Что делать-то?

Спешу обрадовать – универсальный рецепт есть. Ура! Тот самый случай, когда there is a silver bullet. Всё просто – надо пахать:

• Каждое требование заново выяснять с заказчиком – для простоты можно считать, что требований нет, т.к. плохие требования часто запутывают, вместо помощи;
• Подключать тестирование заранее – пусть требования тестят на предмет полноты, непротиворечивости и верифицируемости (к сожалению, помогает только, если специалисты по QA опытные);
• Махровым цветом должен цвести микроменеджмент - как всегда при неопытных разработчиках;
• Защищать своих разработчиков – они ни в чём не виноваты:
  • Иметь в виду, что начальные сроки уже просрочены, просто в силу того, что они были назначены из требований, которых нет. Начальные сроки разработчикам даже озвучивать не надо – озвучивать только то, в чём сами уверены, например срок сдачи первой итерации согласно новым требованиям (заново оценённый и перепланированный);
  • Иметь в виду, что в начальный бюджет вы не попали, просто в силу того, что в нём не было графы “выяснение требований”. Это даже если оценка самих требований не изменятся, а они изменятся;
• Не брать проектов в дополнение к этому. Из опыта известно, что плохой проект “высасывает” время из всей остальной деятельности. Что характерно – при нанесении непоправимого ущерба остальной деятельности, плохому проекту это помогает очень редко. Хз в чём тут дело.
• И не париться, если ничего из этого не помогло. Вернее, конечно надо провести разбор полётов, понять, что таки делалось не так, но без депрессий. Этот пункт применять только, если вы заранее знали, что проект – плохой. Если этот пункт применять к любому заваленному проекту, то ой. плохо. пора уходить в дворники.

Как видим, в принципе, ничего страшного нет. Точно так же, как и нет времени ни на что больше :) Но, тем не менее, “плохой” проект реально вытянуть, надо только взяться за него серьёзно с самого его начала.

А вот тут собственно мы и возвращаемся к началу поста – чтобы разглядеть “плохой” проект, надо внимательно смотреть на все и хорошенько думать… Потому что, если в середине или конце проекта, говорить, что он, мол, плохой – это уже отмазки, и нифига не конструктив.

P.S.: чуть не забыл. Дальнейшее чтение: Эдвард Йордон “Путь камикадзе” (Death March)

Как это продемонстрировать, чтобы а) нескучно, б) задействовать самих студентов, в) не осталось и тени сомнения, что проблема имеет место быть и важна?

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

В общем случает выглядит это так:
ведущий –> –> описывающий –> рисующий –>

Ничего не напоминает? Ну конечно же напоминает – вот заменяем слова ведущий, описывающий и рисующий на соответствующие роли из нашей повседневной жизни и получаем совершенно такую же картинку.
заказчик –> –> сейлс / аналитик –> разработчик –>
На том и порешили – студентам покажем конкурс: не скучно, наглядно и поучительно. А я задумался…

Возникает вопрос – какого хрена так получается? По моему нескромному мнению проблема является следствием широко распространённого мифа про то, что сейлс/аналитик – это человек, которые переводит с языка заказчика на язык программиста.

На первый взгляд всё правильно. Ну действительно, программист (если всё максимально упростить – программист на logo) прекрасно знает, что такое линии и круги, но не знает, что такое человечек, поэтому ему пытаются объяснить человечка в виде графических примитивов. Ситуация усложняется тем, что иногда (часто?) аналитик тоже не знает, что такое человечек и можно легко представить себе такой диалог:

– привет, я аналитик в вашем проекте. Сейчас мы быстро всё выясним и программисты это сделают в лучшем виде. Итак – что же вам нужно?
- это совсем просто: мне нужен человечек!
- ок. нет проблем, для нас это не ново. только надо выяснить некоторые минорные детали – что такое человечек?
- ну… эээ… хм… ну типа кружочек… там под ним идёт вертикальная линия и её пересекает горизонтальная… ага и внизу ещё 2 диагональные из одной точки – это ноги…
- ноги? впрочем неважно. я всё понял – скоро будет, ждите.

Знакомо? Наверняка до боли…

В этом месте многие поднимут руку, чтобы сказать сакраментальное “ну так заказчик же – идиот!”. Так-то оно так, да не совсем… Если рассмотреть этот диалог со стороны заказчика, то после второго вопроса у заказчика наступает стресс (если не шок!) – он встречает человека незнакомого с понятиями, без которых заказчик себя не мыслит. В его кругу общения наверняка нет людей, которые не знают, что такое человечек. И он лихорадочно пытается придумать, как донести до нас “очевидные” вещи. Кстати, можно только догадываться, что думает заказчик про нас в этот момент… :-) Вы можете поставить себя на место заказчика, попытавшись объяснить воображаемому другу понятие “оператор”, не впадая в лекции по языкам программирования.

Есть ли решение этой проблемы? Конечно есть, вот только не всем оно подходит: хотя бы аналитик (а в идеале и разработчик) должен иметь знания из предметной области – бизнеса клиента. Да это трудно, но с другой стороны только так и получаются действительно хорошее ПО. Другими словами, чтобы переводить с языка заказчика, надо этот язык знать, а лучше, чтобы переводить не надо было.

Примеры на каждом шагу. Приведу те, которые мне ближе :-):

• программу для расчётов на прочность топливных баков ракеты-носителя “Энергия” писали специалисты по прочности (одним из них был мой отец, в то время работавший в ХАИ на кафедре прочности);
• во время перестройки спрос на наукоёмкие программы подупал, зато вырос на всякую бухгалтерию. Мой отец сел писать программу всякого учёта (приход, расход, склад, зарплата, налоги и т.д.) и, чтобы написать её он выучил бухгалтерию, т.к. привык делать только то, что понимает. Выучил, кстати, настолько, что впоследствии вместо программирования рулил несколькими бизнесами без нанятого бухгалтера.
• специалисты по юзабилити создают супер удобные операционные системы, настолько удобные, что программисты не могут их не скопировать :-).

Что же делать? Ну для обычных фрилансеров и аутсорсеров в общем ответа-то и нет, кроме как “страдать” :-). Или пытаться стать необычными.

Под необычностью я понимаю узкую специализацию – выучивайте что-то одно (ну или два), но досконально и будет вам счастье. Да, потенциальных заказов будет поменьше (ведь вы искусственно ограничиваете поток клиентов), зато ваш продукт будет выше всяких похвал и есть надежда, что поток будет постоянным. Отцу до сих пор звонят из ЦАГИ и КБ им.Сухого, просят написать кое-что… вот только денег не предлагают, но это уже совсем другая и грустная история.

Это относится как маленьким игрокам так и к большим – например совсем не маленький DataArt смотрит как раз в нужную сторону. И это правильно.

P.S.: да, кстати, я тут подумал, что есть же и гениальные программисты, которые всё понимают, всё могут и всё у них получается. Они не просто есть, они наверняка уже вытащили вилы, чтобы поднять на них меня в каментах… но этот постскриптум добавил мне ауру “броня +15″, так что я спокоен :-)

-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

UPDATE: понедельник, провели эксперимент по рисованию “проектов” и вот результат:

1. Оригинал, рисовал я;
2. Нарисовано с закрытыми глазами, в качестве описания использовались геометрические фигуры. Рисующий знал, что рисует волка;
3. Нарисовано с закрытыми глазами, в качестве описания использовались геометрические фигуры. Рисующий НЕ знал, что рисует волка;

Выводы несколько не однозначные :-)

Иван считает, что №2 гораздо лучше (рисовал он) и это доказывает, что знать что делаешь нужно. Этот рисунок нарисован при минимуме инструкций с моей стороны, а именно 10. Другими словами если разработчик знает, что делать, то при минимальном участии менеджера можно получить приемлемый результат.

Насте кажется, что №3 лучше (рисовала она), но для его рисования потребовалось больше контроля (типа “левее, стоп, теперь правее, линия вниз, стоп!” и т.д.). На этот рисунок понадобилось 33 инструкции. То есть, если микроменеджить, то всегда можно получить приемлемый результат.

Моё же мнение такое – судя по работе, у разработчиков руки из задницы, уволить! :-) Волков рисовать должны те, кто умеет их рисовать…

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

• на модификации системы он потерял кучу времени и денег;
• в итоге новая фича не юзабельна (кататься невозможно);
• модифицированная система нестабильна и расширению не подлежит;

Кто тут больше виноват? Клиент ли должен был тщательнее описывать свои требования, аналитик ли должен был тщательнее уточнять требования клиента?

По моему нескромному мнению виноват больше тот, кто понёс большие убытки. А вы как думали? В мире всё справедливо и степень вины можно увидеть по размеру наказания.

Это кстати интересный мотивационный вопрос – надо будет его как-нибудь попозже рассмотреть детальнее.

Теперь начинаем думать, а что же разработчик? Может ли он быть виноват в ситуации с “подразумеванием”? А то! Я там вам очень поучительный анекдот вспоминал… так вот и он:

Красная Шапочка, абсолютно голая, лежит под деревом в лесу. Мимо проходит Серый Волк и говорит:
- А ты не боишься? Ведь в этом страшном лесу с тобой может произойти множество самых ужасных вещей!
- Да я именно этого и жду, – подмигивает Шапка.
- Понятно, – сказал Волк и сломал ей ногу…

Если кто думает, что это не относится к нам, то я могу анекдот перефразировать:

Поймали сейлы клиента и давай у него проект выпрашивать. Клиент им описал примерно, чё он хочет; сейлы сделали документ – суют клиенту. Тот читает и говорит:
- А вы уверены, что мы можем начинать? Я думаю вы должны мне задать ещё несколько вопросов!
- Да ну, – отвечают сейлы, – что за глупости? Пора бежать!
- Понятно, – сказал клиент и подписал fixed-cost контракт…

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

Я не говорю, что намёки недопустимы… просто надо быть on the same line с тем, кому намёк адресован :)