Эфективное софтверное тимлидерство

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

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

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

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

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

Итак, что делать?
Доверие по части качеству кода - проверить первично, если потребуется включать режим коачинга (учить и контролировать). Если не получилось, заводить как руки для более смышленого товарища (таких людей должно быть мало).
Доверие по части открытости - нести открытость как флаг. Все должно быть пронизано открытостью, в первую очередь со стороны менеджера. Учить людей быть открытыми и не бояться. Наказание за открыто доведенную проблему или косяк - табу. Авторитарный стиль управления не способствует открытости. Применяем его только в кризисных ситуациях.
Доверие по части проектирования посложнее. Тут очень к месту будет стиль руководства "учитель", когда начальник учит подчиненных своему образу мышления. Расширять людям угол обзора, а затем и уровни проработки, от технологического до уровня эксплуатации заказчика или рыночных реалий. Тут ни о каком контроле конкретно выполненных работ речь не идет, тут надо слушать, что говорит человек при общении как с менеджером, так и внутри команды, какая аргументация присутствует, какие детали подмечаются, на что акцентируется внимание. Далее разбираем кейсы, приводим примеры и аргументы тот же коачинг, но измеримый контроль отсутствует.

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

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

Личностные качества

• Обязательность и аккуратность • Умение выражать свои мысли на бумаге (написание требований и спецификаций)
• Проживание: Зеленоград, ближайшие районы или желание переехать

http://hh.ru/vacancy/4424249

Провел небольшую реорганизацию в группе. Теперь команды выглядят более сбалансированными. Они могли бы быть сбалансированы по нагрузке, компетенциям, экспертизе, ролям, но это не главное. Это не просто объяснить, но энергетика группы - это самое главное, сейчас я попробую это разложить.
Что такое энергия команды, спросите меня вы, покручивая пальцем у виска - "Ты еще про темную материю расскажи и колдунов-алхимиков.". Нет, кроме простых человеческих качеств, бывает и такое - чувство энергетики коллектива. Чем больше ты взаимодействуешь с коллективом, тем больше чувствуешь дух этих людей - каждого в отдельности и всех вместе. Какие-то группы людей вредные, нарочито направленные на удовлетворение только своих интересов, затруднены отношения с окружением - сразу видно - интраверты, ничего у ребят ничего масштабного не получится, так и будут ползти как жабки.
Другие - все такие профессионалы, автономные биороботы, берут и делают и все четко, но работают ли они как одна команда, нужны им статус встречи? Нет, но у этой группы есть дух и заключается он именно в этом - это энергетика группы профессионалов, зачем взаимодействовать, ведь каждый хорошо делает свою работу. Взаимодействовать с этими людьми как с группой можно только посредством лидера, такого же профессионала, не нуждающемся в помощи коллег - и это другая форма интравертности. Дух это что-то неуловимо общее в поведении и коммуникациях людей. Это тот полюс к которому устранены стрелки их компасов. К великому сожалению, я не чувствую духа своей группы, глаз замылен.
Чего хорошего в этих изысканиях, спросите вы.
Когда у группы есть дух, ребята иду все в одном направлении, они действую процессно или эмоционально сообща, они могут не быть командой по части взаимодействия, но имею общее, если хотите коллективное бессознательное.
Когда дух группы известен, подобрать к нему "ключик", позволяющий взаимодействовать как с коллективом, так и с каждым в отдельности, проблемы не составит. Люди у которых есть хоть что-то общее управляемы. Это существенно упрощает коммуникации, как внутри, так и во вне. Группа сама показывает свой дух - это могут быть плакаты на стенах или специфичное поведение членов группы, своя "культура" общения. Со временем ожидания других людей, , впитывающих эти вербальные и не вербальные сигналы, от группы скорректируются и настанет сбалансированность "хотят - можешь". При формировании организационной структуры нужно подобрать человека вливающегося иначе ему придется ломаться или будет не интересно, что может вылиться в fail.

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

Цитаты:
"Цикл.
Сначала мы использовали итерации, но отказались от них полтора года назад. ..."
"Оценки.
Мы не оцениваем фичи и юзер стори. Раньше мы проводили planning poker и оценивали истории в абстрактных поинтах, однако сейчас стараемся просто фокусироваться на самых важных вещах. ..."
"Митинги.
Когда-то у нас было много митингов: ретроспектива, планирование релиза, планирование итерации, daily standup. Сейчас из регулярных остался только daily, все остальные собрания проходят исключительно по мере необходимости для решения конкретных задач. ..."
"Рабочее время.
Раньше мы отслеживали все потраченное время, сейчас перестали это делать. Люди работают сколько хотят. ..."

http://habrahabr.ru/company/taucraft/blog/112854/

Пришло время UPнуть идею, которая мне пришла в голову в порядке бреда около года назад.

1. При прохождении срочной службы рядовые проходят обучение в разработке
2. Много времени для практики на реальных проектах, компетенции, опыт
3. ???
5. PROFIT

Отрасль накачивается новыми специалистами.
Призыв увеличивает набор.
Отбираются только годные.

Про последнюю мысль стоит рассказать отдельно. Давным-давно я проходил военно-патриотические сборы в части под г. Ковров. Я танкист. И знаете какая мотивация была у танкистов срочников? Плохо учишься, пойдешь в пехоту по грязи ползать. Аналогичная мотивация на хорошее обучение есть и в 1ой разработческой роте - никто не хочет из теплого казарменного опенспейса переместимться в грязь в лучшем случае в АЗК после команды "вспышка слева".
Опытные и дисциплинированные специалисты после прохождения срочной-разработческой определенно будут востребованны на рынке. Работодатель может ознакомиться с характеристикой. Можно грабить корованы.
Что скажете, тов. Сергеев?

Что-то такое менеджер без зоны ответственности? Правильно - консультант. Но речь в данном случае не о них, хотя роль замечательная. О ней как-нибудь в другой раз. Итак, менеджер - человек с зоной ответственности. Эта зона может быть как неким проектом, так и подсистемой, которая находится в процессе развития. Вот о ней то мы и поговорим.
Софтварные менеджеры в отличии от гражданских должны иметь прокачанный технический бэкграунд. Быть не только руководителем, но и архитектором, разработчиком, тестировщиком. А кто говорил, что будет легко?
Про то, что пишут в книгах для проджектов (планирование, постановка задачи, контроль, делегирование), говорить не будем.

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

Еще давно на конференции http://softwarepeople.ru/ я подметил необычайно обширные знания Константина Кондратюка (http://www.careerlab.ru/education/guru-academy/kondratyuk/). Именно этот человек поразил меня "птичкой и жабкой". Это про людей: одни летят высоко видят далеко, но не видят детали внизу; жабки, напротив, ползут по земле, не видят ничего дальше, но прорабатывают детали.
Сходил на отличный тренинг Константина «Управление командой технических специалистов» (http://www.careerlab.ru/education/guru-academy/kondratyuk/sem6/). Я хочу сказать, что это отлично: много личного опыта, выделение особо важных областей, тесты, игры, разбор ситуаций, советы на прокачку менеджерских скилов. Сам Константин отлично работает с аудиторией, чувствует ее, динамично перераспределяет основные темы, примеры выдает сходу.
Единственное, мне показалось, что мы пробежались по верхушкам, не сильно вдаваясь в подробности. Это несколько обидно. Это как знать, что используешь только 3% мозга - обидно, но ничего не сделаешь.
Ощущаешь прилив сил, понимаешь что "все сделал правильно, сынок". Хватает его на месяц-два.

Начало
Началось все с того, что я собрал команду в полном составе в столовке и кратко объяснил, что мы будем сейчас играть в planning pocker (карты я заблаговременно распечатал на стратегично "выпаленном" цветном принтере). В качестве единицы изменения были приняты Spell Story Point'ы, которые для простоты мы приравняли к идеальному MD, ведь задачи системы очень неоднородны. Первый блин планирования получился комом – мы два часа убили на обсуждение деталей реализации первой задачи. Зато на следующий день нам удалось оценить все важные задачи (на каждую задачу уходило по 20 минут), а в конце мы демократизировали задачи на "стикеры" – подзадачи. Планирование спринта отняло у каждого члена команды 8 часов рабочего времени, но я уверен, что это время окупится сполна.
Купить кусок пенокартона и приспособить его в качестве скрам-доски не составило особго труда, ведь рядом оказался замечательный магазин Передвижник. Спринт мы выбрали равным 4 недели, что соотвествует внутренним итерациям разработки системы целиком, а фокус фактор равным 0.5. И вот что получилось.


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

В воздухе давно витает настроение agile:
AGILE, agile, аджайл, гибкий, агила
Еще сам великий учитель al_mamontov, когда открывал мне глаза на мир разработки ПО, аккуратно давал мне всякие книжки про TDD и экстремальное программирование. Сейчас же я бы сказал гибкие методологии очень активно насаждаются. Подтверждением этого служит программа конференции Software people 2010, на которой мне посчастливилось побывать в качестве почетного гостя. Практически вся колонка Process Management посвящена гибким методологиям и в частности scrum. Ни на одно из выступлений из графы Process Management я, к сожалению, не попал, так как в это время шли очень интересные выступления в направлении "People Management". Да и зачем мне туда ходить, когда живой пример трудится под боком менеджером в дружественной команде разработки системы самообслуживания абонентов. Ребята уже несколько месяцев как практикуют scrum, причем, умудряются это делать в условиях жестких сроков, спускаемых сверху, ограниченности ресурсов и неизменяемого объема задач.
Я же до последнего времени находился в аморфном в отношении AGILE состоянии. Кроме разве что экстремального программирования, а именно разработки через тестирование, но с укрупненными итерациями – одновременно с тем как задача берется разработчиком, модульный тестировщик начинает по HLD писать автоматические или unit тесты, которые проверяют в последствии, что написанный код работает как написано в писании солюшн архитектора.
Добил меня известный исследователь-практик отрасли разработки ПО – некто Петр Хрюшка, который на своем семинаре рассказывал научные обоснования почему гибкие методологии и укороченный цикл поставки это хорошо. Я то в принципе не против гибких методологий и укороченных циклов выпуска ПО, да все как-то руки не доходили продумать подводные камни и внедрить у себя в команде, но тут свершилось – я прочитал классную книжку, где мастер боевого НЛП рассказывает, как они внедряли скрам и делится некоторыми практическими соображениями. Оставшиеся вопросы постарался развеять предводитель той самой системы самообслуживания и от части у него получилось, но главный его мессадж звучал так "а как ты поймешь что делать, пока сам не попробуешь на практике" и мол не задавай мне свои абстрактные вопросы про коней в вакууме.
Однако скрам предлагает не только практики программирования. Мне понравился подход этой методологии к оценке трудозатрат и рисков, распределению и планированию задач, отслеживанию статуса проекта и исключения эффекта Mañana, а так же очень важному моменту извлечению уроков и процессу улучшений.
Статья: "Хорошие идеи в скрам"
Статья: "Внедрение практик скрам"