Но менеджеру всё равно не так легко объяснить заказчику, что на проекте проблемы. Заказчик же видит, что всё идёт по плану. Тут можно достать этот внутренний план и объяснить, когда релиз должен был быть закончен на самом деле. Заказчики очень спокойно относятся к заложенным буферам, а особенно к буферам в виде сдвига дат. Ведь они им ничего не стоят!
Но надо понимать, что иногда такие бесплатные буферы стоят реальных денег для заказчика. Например, вы заложили в план, что API внешней системы будет готов на месяц раньше, чем он вам реально нужен. Так вот иногда заказчику оказывается гораздо дороже сделать этот API в срок, чем задержать его до того времени, когда он вам реально понадобится.
И здесь начинаются сложности, потому что вы можете пойти навстречу заказчику и согласиться получить API на месяц позже. Но тогда вы берёте на себя дополнительные риски. Если этот API будет с ошибками, или недостаточно документирован, или у вас будут проблемы с доступомваш проект будет терпеть убытки. Но с другой стороны, если дать заказчику больше свободы, то есть больше шансов, что API будет качественным.
В такой ситуации бесплатный буфер внезапно начинает стоить денег и уже нужно определять, кто эту цену платит и на каких условиях.
Я придерживаюсь стратегии, что если мы говорим о ранних сроках реализации проекта и оговоренные условия пойдут в контракт, то мы должны давать только безопасные даты. Чем безопасней, тем лучше. А вот если проблемы выплывают ближе к запланированной дате, то уже можно проявлять гибкость и сдвигать даты по договорённости с заказчиком, уменьшая бесплатный буфер. Но нужно быть очень прямым и объяснить заказчику в том числе и в письменном виде, что любые уменьшения буферов увеличивают риски. Тогда можно избежать расплаты за использования бесплатных буферов.
История про проведение ретроспективы
На одном из соседних проектов было очень много проблем. Релизы откладывались, даты срывались, а качество приложения было низким и неуклонно падало. В результате, несмотря на все усилия, проект закончился полным провалом, наша компания серьёзно подвела заказчика.
Чтобы понять, почему так произошло, организовали ретроспективу. Руководитель проекта, в лучших традициях скрама, давал всем высказаться и выписывал на доску длинный список всех проблем, которые команда называла. Опять же в лучших традициях ретроспектив, сперва давали высказываться junior-ам, чтобы более опытные члены команды не давили своим авторитетом. Самым последним слово досталось лиду разработки, очень опытному архитектору, Петру. Пётр был краток:
Вы вот все много разных причин назвали, но самую главную упустили. Очевидно, что проект завалился только из-за одного: тестировщики нашли слишком много багов. Из-за них-то мы и не смогли в срок выпустить приложение.
Команда тестирования, не веря своим ушам, дружно стала возмущаться, но Пётр поднял руку, призывая всех к тишине.
Я вижу, что не все согласны с моей точкой зрения. Давайте придерживаться регламента. Все названные командой проблемы выписаны, так что давайте просто проголосуем.
Команда разработки была примерно в два раза больше команды тестирования. Они все дружно проголосовали вслед за Петром за названную им проблему. На этом ретроспектива была закончена. По её результатам причиной провала проекта считалось, что тестировщики нашли слишком много ошибок. Половина тестировщиков после такой ретроспективы пылала гневом, другая половина была, как в воду опущенная.
Хотя я к тому проекту не имею отношения, но мне до сих пор стыдно перед теми тестировщиками. Мои соболезнования, коллеги. Мне очень жаль, что такие истории случаются в реальности.
Раздел 5. Становление менеджера
Под конец книги логично поговорить о том, как менеджер начинается. Путь от специалиста к менеджеру у каждого разный, но если достаточно долго наблюдать за разными путями, то можно увидеть много похожего. Давайте посмотрим на эти похожести вместе.
Менеджмент: начало
Неправильно относиться к понятию менеджер как к названию должности. В IT, в отличие от многих других областей человеческой деятельности, человек может не иметь никакой руководящей должности и даже категорически отказываться от позиции менеджера, но вполне себе заниматься руководством и фактически быть руководителем. Менеджерэто человек, который хочет и может управлять, а должность приходит гораздо позднее.
Давайте рассмотрим, как проявляется склонность к менеджменту у разработчиков. Пока разработчик просто сидит и пишет код, он проявляет только свои технические навыки. Но реальные проекты всегда подкидывают какие-то проблемы. Вот, например, прилетает на разработку новая задача и разработчик, читая требования, видит, что с требованиями беда: есть противоречия, есть не покрытые описанием ситуации, есть неконсистентность интерфейса между разными частями системы.
Любой опытный разработчик не сможет просто игнорировать такую проблему. Как минимум он скажет о проблеме менеджеру и спросит, что делать. Это обычный подход исполнителя и это нормально.
Но некоторые разработчики в такой ситуации делают больше. Они подойдут к тестировщику, назначенному на ту же задачу, и обсудят проблему с ним. Потом они вместе с тестировщиком пойдут к аналитику, вместе всё обговорят и придумают какое-то решение. К менеджеру уже они придут все вместе и не с проблемой, а с решением. А чтобы проблема не повторялась в будущем, разработчик может предложить ввести этап ревью требований командой.
Все эти дополнительные действия делаются с подачи такого инициативного разработчика. Фактически он частично выполняет менеджерские функции, организуя процесс разработки и активно участвуя в процессе принятия решений. Этот подход назовём тимлидским, так как такие шебутные разработчики становятся потом тимлидами, а чуть позднее менеджерами.
Надо заметить, что исполнительский подход не хуже и не лучше тимлидского. Это скорее вопрос личных предпочтений человека. Конечно, компания тоже должна соответствовать этим предпочтениям. Разработчики, которые не хотят даже минимально лезть в менеджмент, выбирают компании, где процессы установлены, где роли строго распределены, и где накладки являются редкостью. В таких компаниях описанной проблемы с требованиями, скорее всего, не возникнет. А если она и возникнет, то от разработчика самодеятельности ждать не будут.
Тимлиды же нормально себя чувствуют в условиях лёгкого бардака и готовы менять процессы и меняться самим. Они оседают в стартапах и других проектах, где ценят их готовность обсуждать и решать проблемы там, где они обнаружились.
Чтобы проявлять такую активность, разработчик должен хорошо понимать процессы, которые уже есть в компании, знать, кто и за что отвечает, понимать, что ему самому нужно для работы. Поэтому чаще разработчик учится быть тимлидом, поработав хотя бы пару лет в компании. А вот после получения навыков тимлидства в какой-то одной компании, он может и в другой компании сразу начать работать на 100%.
Разработчик может не интересоваться изменением процессов, но ему может быть интересно что-то другое из арсенала менеджерских умений. Возможно, ему интересно общаться с заказчиком и разбираться в нуждах бизнеса. Тогда он и будет этим заниматься. Или он чутко реагирует, когда кто-то рядом расстроен, и умеет (или хочет научиться) это исправлять. Тогда он будет прокачивать свой эмоциональный интеллект.
Иногда считается, что такие тимлиды обладают меньшей производительностью, чем исполнители. Ведь в то время, как исполнители пишут код, тимлиды занимаются какой-то не относящийся к реальной работе деятельностью: собирают митинги, пишут письма, подготавливают документы для заказчика. На самом же деле тимлиды экономят команде и заказчику много времени. Они замечают проблемы на ранних этапах, когда их можно исправить относительно просто. А таких проблем в проектах обычно очень много.
Индустрия разработки программного обеспечения очень нуждается в тимлидах. Конечно, это показатель недостатка опытных менеджеров, причины которого мы уже рассматривали, но кроме того, это отличная возможность для разработчиков получить менеджерские навыки и оказать реальное влияния на проекты.
История про менеджмент не в IT
Мне очень нравится смотреть на то, что происходит не в IT. Некоторые проблемы там выглядят совсем по-другому и решаются оригинально. Очень полезно перенимать такой опыт. Я хочу поделиться одним примером моих наблюдений.
Я много лет слежу за развитием одного математического кружка. Этот кружок полностью коммерческий, то есть родители оплачивают обучение детей там, но он государственный, дочерний для крупного ВУЗа.
Несколько лет назад он был совсем небольшим, пока там не появилась молодой преподаватель, Аня. Аня с душой подошла к делу. Она узнала, как работают конкуренты, она продумала позиционирование кружка на рынке, она общалась с родителями, узнавая что им нравится, а что нет.
Никакой специальной должности Аня не имела, она была просто преподавателем. Но ей удалось убедить руководство кружка, что нужно вложиться в маркетинг. Бюджета на рекламу всё равно не было, но Ане разрешили рекламировать кружок, как она считает нужным. Этого согласия оказалось достаточно. Аня нашла возможность привлечь студентов из шефствующего ВУЗа, уговорила знакомых помочь ей с разработкой материалов, сама проводила многочисленные мероприятия, разработала сайт, развила деятельность в соцсетях. Фактически она выполняла менеджерские функции, хотя формально она была рядовым преподавателем. Она определяла лицо кружка и руководила маркетинговой работой.
Вывод 1: Менеджеру не нужны ни должность, ни дополнительная зарплата, ни даже особые ресурсы. Менеджер делает свою работу, потому что она ему нравится.
Чего удалось добиться Ане? За несколько лет кружок вырос в 10(!) раз. Далеко не все желающие могли поступить на обучение, появился конкурс. Аня помогала привлечь хороших преподавателей и перспективных учеников. Конкурентов у этого кружка в городе не осталось. Из явных аутсайдеров кружок стал абсолютным лидером. Коммерческий успех был несомненным.
Вывод 2: Всего один человек может изменить очень многое и привести компанию к успеху, просто если ему не мешать.
Потом Аня по не имеющим отношения к делу причинам переехала в другой город. Её работу оказалось некому выполнять и в принятии решений стало принимать участие прежнее руководство, которое и раньше существовало, просто позволяя Ане делать, что она хочет.
Что это прежнее руководство начало делать в первую очередь? Сокращать количество учащихся. Причём они не просто повысили сумму за обучение, чтобы сохранить прибыль. Они стали делать условия оплаты более трудными для родителей, объявляли непонятные условия обучения, делали хуже условия для преподавателей. Устно обоснование было простым: У нас очередь на обучение, так что если кто-то не хочет у нас учиться, то только лучше станет.
Мне казалось, что руководство просто проф.непригодно. Так планомерно разрушать созданное другими могут только ужасно недальновидные люди, ведь так? Но когда я поузнавал получше, выяснилось, что зарплата у руководства не зависит от числа учащихся и от величины прибыли. То есть обучать 300 человек им нисколько не выгодней, чем обучать 30. Но ведь работы объективно больше!
То есть это с моей точки зрения Аня делала хорошее дело, позволяя большому числу детей получить дополнительное образование. А с точки зрения аниного руководства она скорее создавала лишнюю работу.
Вывод 3: Если вам действия какого-то менеджера кажутся ошибочными, то возможно, он просто руководствуется совсем другими целями, принципами и мотивами. Он может быть очень эффективным, просто не в том, что вам кажется важным.
Ну и общий вывод: Менеджеру нужно найти такое место работы, где то, что он делает, будут ценить и поддерживать. Только так можно быть уверенным, что результаты вашей работы будут сохранены.
Первое задание менеджера
Хотя менеджерэто скорее состояние души, чем роль или, тем более, должность, но формальное присвоение должности менеджер всё-таки важно. Официально признанный менеджер имеет доступ к дополнительным ресурсам. Очень часто бывает так, что разработчик очень быстро вырастает до тимлида и проявляет задатки будущего менеджера проектов, и сам он не против стать менеджером, но всё как-то не срастается. Так вот первое задание такого начинающего менеджераэто добиться менеджерской позиции!
Для начала давайте рассмотрим, почему возникает такая заминка в карьере:
Менеджер проектов не отвечает за рост тимлида выше по менеджерской иерархии. Если от junior-разработчика до тимлида его менеджер двигает человека сам, то продвижение выше он уже обеспечить не может. Решение о таком продвижении должен принять менеджер менеджера, либо даже оба руководителя отделов, менеджмента и разработки, либо даже генеральный директор. Конкретный путь зависит от структуры компании, но менеджер того проекта, где работает тимлид, играет второстепенную роль.
Да, конечно, менеджер скажет, что его тимлид хочет и, наверное, может стать менеджером, но решение будет принимать другой человек, который напрямую с тимлидом не работает. Соответственно, и все решения принимаются гораздо дольше и сложнее.
Шаг от тимлида к менеджеру значительный. Гораздо более значительный, чем рост от Middle до Senior разработчика, например. Если тимлидом разработчик может стать очень плавно и безболезненно, то шаг к менеджеру означает смену экспертизы и требует очень много усилий от самого тимлида да и от других людей тоже.
Если повезёт, то тимлид может получить много знаний от своего текущего менеджера или из каких-то тренингов. Но не все менеджеры имеют педагогический талант и время заниматься обучением тимлидов нетривиальным менеджерским трюкам, а менеджерские тренинги обычно имеют крайне опосредованное отношение к реальной работе.
Да, часто тимлид может кое-чему научиться, наблюдая за менеджерской работой со стороны. Но есть очень много областей, куда тимлид доступа не имеет: решение некоторых конфликтных ситуаций с сотрудниками или переговоры с заказчиком.
Например, попытку удержать увольняющегося сотрудника менеджеру лучше делать с глазу на глаз, иначе задача усложняется в десять раз. А даже если переговоры с заказчиком тимлид может наблюдать со стороны, то те же переговоры имеют совсем другой вид, когда ему нужно принимать решения.
Психологически шаг к менеджменту также велик. У менеджера просто взгляд на вещи другой. Причём разным тимлидам тяжело даются разные вещи. Например, кого-то может просто убивать то, что менеджера отвлекают каждые несколько минут. А кому-то другому будет сложно впитать идею, что принять решение быстро обычно важнее, чем принять решение правильно. А кто-то дойдёт до нервного срыва, когда поймёт, что за любые неудачи его даже самых нерадивых подчинённых отвечает он сам.
Чтобы преодолеть эту психологическую пропасть, тимлид должен быть очень мотивирован. Он должен очень-очень хотеть стать менеджером, чтобы побороть все сложности, о которых он даже и не знает. Но если он так мотивирован, то почему он не становится менеджером? Задача не такая сложная и для менеджера обычная. Ему придётся на своём проекте постоянно устанавливать свою позицию относительно команды и заказчика. Почему он не может установить свою позицию в компании? Видимо, не так уж хочет. А раз не так уж и хочет, то не сможет вынести напряжения менеджерской роли.
Это, кстати, менеджерский взгляд на вещи, к которому тимлиду надо как-то прийти.
Менеджеру нет выгоды делать менеджера из тимлида, ему это, скорее, приносит проблемы. Вот, кстати, хороший тест на менеджерской мышление. Большинство разработчиков, прочитав начало этого пункта сформулируют в голове какую-то такую мысль: Ага, значит мой менеджерэто мой враг! Он будет мне мешать! Как только я захочу стать менеджером, он меня возненавидит! Эта мысль неправильная. Менеджеру гораздо сильнее надо разделять эмоции и работу, чем разработчику.
Этот пункт не означает, что менеджер плохо относится к тимлиду, который рвётся в менеджмент. Менеджер может очень сильно помогать такому тимлиду. Но буквально плюсов самому менеджеру нет, так как на его проекте положительно это не скажется. А вот негативно скажется наверняка, так как тимлид с него уйдёт.