Менеджмент | Владимир Бычко об управлении проектами - Part 4

Владимир Бычко об управлении проектами

пиэм разъясняет, предостерегает, рекомендует

Категория: Менеджмент

Мысли за последнее время

Несколько заметок из линкадина, чтобы не потерять.

Разрешайте программистам проёбываться

Важная мысль. Разрешайте программистам проёбываться.

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

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

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

Ночью воскресенья прибыл в Калининград, дошёл до своей общаги, лёг спать, выспался, а потом написал все недостающие РГР-ки, сдал экзамен на «хор» и навсегда усвоил, что иногда надо переключаться.

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

* * *

Как казаться умным

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

* * *

О важности «нет»

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

А в реальной практике менеджера проектов говорить «нет» приходится постоянно.

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

Пообщался с пятерыми подрядчиками для нетипичной доработки, выбрал одного, остальным надо сказать «нет». Блин, но люди же потратили на меня время, сделали оценку, а я такой мудак.

Провёл собеседование с кандидатом во фронтендеры, вроде, нормальный, но есть сомнения. Дал тестовое, он его неделю пилил и сделал ну прямо плохо. Рецензент говорит, человек совершенно не понимает современные тренды фронтенда, его надо полгода дообучать. Но как же жалко, мы потратили время на собеседование, он потратил время на тестовое, а надо сказать «нет», вот я мудак.

Вы не мудак, говорить «нет» нужно, иначе ничего у вас не выйдет. И контрагенты, которым приходится отказывать — не ваша мама, они не обидятся, а будут искать другие возможности.

* * *

Стой, раз, два

Специалисты Красного Креста в начале обучения спрашивают, какое должно быть первое действие при оказании первой помощи. И это действие — не проверка пульса и даже не дыхательных путей. Это действие называется «стой, раз, два». Буквально, остановиться и пять секунд подумать.

Изображение с society6.com

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

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

Для кого-то три часа — это много и он успевает успокоиться и принять взвешенное решение за сорок минут, но в целом концепция одна. Стой, раз, два.

* * *

Проектные и процессные люди

Среди не слишком квалифицированных руководителей бытует мнение, что люди бывают, ориентированные на результат и на процесс. Первые добиваются целей, вторые просиживают штаны. Это всё херня. 

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

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

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

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

* * *

Стратегическое планирование

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

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

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

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

* * *

Уменьшение количества багов

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

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

Практика простая, но при её регулярном применении количество дефектов уменьшается.

* * *

Рассылка об увольняющихся

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

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

Мне кажется, такую рассылку надо делать, информируя о том, что человек уходит, в день написания им заявления. Ну и писать, кому он передаёт дела.

* * *

О крикунах

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

Изображение с creativemarket.com

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

* * *

Сбрасывающийся параметр

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

Так родился один из самых мерзких дарк паттернов в дизайне — опция, которая через некоторое время сбрасывается в исходное состояние. Пример — переключатель умной ленты в линкадине. Можно отобразить «последние» новости, но она через пару дней опять возвращается в состояние «популярные», в котором месяцами наверху висят одни и те же пять постов.

* * *

Концепция играющего тренера не работает

Давным-давно, в одной софтверной компании у меня вышло глобальное непонимание с IT-директором. Он хотел, чтобы я, будучи руководителем продукта, самостоятельно собирал и писал требования хотя бы к части доработок и их потом «продюссировал».

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

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

Так вот, сегодня вычитал в одной бизнес-книге, что для того, чтобы стать руководителем системы, обязательно нужно перестать быть её частью. Схема «играющего тренера» не работает. Нельзя быть руководителем на 99 %, есть принципиальная разница между управленческим и исполнительным трудом и исполнять их эффективно одновременно невозможно.

* * *

О насыпании задач

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

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

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

На следующий день шеф сказал, что я не молодец и он штрафует меня на 500 рублей (дело было примерно в 2012 году и платили мне в районе 25000 руб и штраф был осязаем). Я сказал, что штраф несправедлив, он ответил, что не согласен и всё равно, штрафует. В итоге я отправил резюме в другую компанию и через неделю уволился, оставив работодателя без бизнес-аналитика, делавшего изрядную часть работы. Это, конечно, достаточно экстремальное решение, многие сотрудники такие штрафы спокойно терпели, но я всё равно, настоятельно рекомендую, если сотрудник сделал 8-9 задач из 10, всё равно, его хвалить, тогда мотивация у него будет на уровне.

* * *

О типах задач

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

Иными словами, нет ничего ценного в том, чтобы уметь складывать 2 и 2, нужно уметь определить, что складывать нужно именно их.

Пять стадий жизненного цикла команды

forming, storming, norming, performing

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

Изначально модель содержала forming, storming, norming, performing. Через 12 лет её дополнили (при участии Мэри Энн Дженсен) пятой стадией, adjourning. Первая стадия начинается с момента формирования команды, последняя заканчивается успешным завершением проекта и расформированием команды. На мой взгляд, мини-версию этой модели команда также проходит при назначении нового менеджера. 

Пиэму крайне важно эту модель знать, чтобы понимать, на какой стадии команда и как перейти к следующей стадии. Давайте разберём их все. 

Forming

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

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

Также на постановочных встречах надо проговорить основные пункты регламента работы, структуру управления (если предполагается несколько начальников) и какая нужна отчётность. 

Storming

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

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

Штормить может долго, но если члены команды и менеджер адекватные, этот процесс не занимает дольше месяца. 

Norming

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

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

Performing

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

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

Adjourning

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

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

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

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

Директивно-вопрошающий стиль управления

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

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

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

Хороший менеджер должен одинаково хорошо владеть как директивным, так и вопрошающим стилем и уметь их применять.

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

Уважение

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

Однако можно применить эту группу приёмов и управлять будет намного веселей. 

Контроль поручений

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

Цели и приоритеты

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

Распределение обязанностей

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

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

Внутренний пиар

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

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

Критика

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

А надо ругать результат его работы. Или отсутствие результата. «Олег, ты же опытный сотрудник и прекрасный человек, но то, что ты сделал в рамках последних задач, никуда не годится, потому что…» Ну и помните мантру о том, что критиковать нужно лично, а хвалить публично. Хвалить тоже нужно и тоже за результаты.

Микрокоманды в разработке

Если загуглить слово «микрокоманда», поисковик возвращает множество статей про устройство микропроцессоров. Я хотел бы рассказать о немного другой микрокоманде — практике группового подхода к разработке. 

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

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

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

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

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

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


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

Семь типов руководителей, работать на которых не надо.

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

Тиран

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

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

Демократ

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

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

Рукастый

Такие руководители вырастают из лучших (в прошлом) специалистов. Это хороший продажник, программист, тестировщик, дизайнер, которого повысили. Больше всего на свете он любит «показывать класс» подчинённым, выполняя самые ответственные участки работы лично. Коллектив с большой радостью каждый раз просит его «показать класс», а потом громко аплодирует, болтая свешенными с шеи руководителя ногами. Так «показывать класс» можно до пенсии. 

Экспериментатор

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

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

Жертва

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

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

Микроменеджер

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

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

Невидимка

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

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

Созвоны с коллегами в Scrum

В целом, я не люблю созваниваться. Во время групповых созвонов в моём сознании тикает таймер суммарных трудозатрат на этот созвон, который компании придётся оплатить. Один час на шестерых = шесть человекочасов. По самым скромным оценкам, двенадцать тысяч рублей за поговорить, а если там программисты, то и больше. 

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

Оценка задач

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

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

Статус

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

Планирование спринта

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

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

Ретроспектива

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

Демо

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

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

Дейлики

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

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

Неприкосновенность оценки

Принцип неприкосновенности оценки

Во многих небольших айти-компаниях есть такая практика. Сейл поговорил с заказчиком, договорился об определённом сроке разработки продукта и этот срок спускается разработчикам. Я ранее писал об этом в статье о пяти признаках проекта, который провалится

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

Однако есть ещё одна проблема. Команда просит два месяца и через два месяца выясняется, что не успели. Вылезли непредвиденные технические сложности, заказчик накидал забытых требований, возникли проблемы с интеграцией с внешними апихами, много всего. И начинаются «вторые 80 %» проекта. 

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

Первые шаги менеджера проектов на новом месте работы

О первых шагах менеджера проектов на новом месте работы

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

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

Базовые вопросы

  • Предоставить компании личные документы. Перечень вам пришлёт эйчарыня, он зависит от типа трудоустройства. В некоторые компании нужен только паспорт, в другие — паспорт, ИНН, СНИЛС, в третьи попросят ещё и скан трудовой, военник и диплом. 
  • Уточнить, будет ли обмен бумажными документами. Иногда, особенно при белом трудоустройстве, бумагой обменяться придётся. 
  • Договориться о том, как часто и куда вам будут перечислять зарплату. Зарплатного рабства в РФ нет, вы вольны попросить переводить на карту любого банка. Я однажды столкнулся с компанией, перечисляющей зарплату в долларах, но при этом сотрудница, ответственная за зарплату, не умела переводить на расчётные счета, только на карту. На такой случай хорошо иметь валютную карту, идеально подойдёт Тинькофф Блек. 
  • Получить доступы. В первую очередь, это корпоративная почта (уточнить, где она хостится), мессенджер, таск-трекер, система документации. Имеет ли смысл конфигурировать десктопный почтовый клиент — вопрос дискуссионный, я предпочитаю это делать, пользуюсь дефолтным маковским почтовиком. Кроме того, в некоторых компаниях для доступа к внутренним ресурсам нужен vpn.
  • Уточнить, нужно ли отписываться, если хотите отойти от компьютера в рабочее время, если нужно, то кому и где. Заодно уточните политику, относительно больничных.
  • Уточнить, в какое время нужно быть на связи обязательно. 
  • Если вы блогер, уточните у эйчарыни, какова политика конфиденциальности, можно ли рассказывать о проектах в соцсетях и блогах. 
  • Уточнить, есть ли в корпоративной вики раздел для новичков, если есть, неспешно прочесть. 

Общепроектные вопросы

  • Уточнить, кому именно вы подчиняетесь. Часто это не тот человек, который вас собеседовал. Уточнить, кто будет принимать решение об успешности прохождения испытательного срока. Обычно это тот, кому вы подчиняетесь, но не всегда. Уточнить, насколько вы независимы от этого руководителя, какие вопросы надо на него эскалировать, какие решать самому. 
  • Узнать ожидания руководителя от вашей работы. Лучше в виде ментокарты или, в крайнем случае, гуглодока, чем подробней он их опишет, тем лучше. 
  • Уточнить, какие отчёты о вашей работе с какой периодичностью нужно передавать руководителю. 
  • Уточнить, кто занимается договорной работой по проектам. Обычно пиэму это не требуется, но бывают компании, в которых вам придётся участвовать, как минимум, в подготовке актов приёмки. 
  • Уточнить, какой софт принято использовать для календарно-сетевого планирования. Он нужен даже при работе по скраму-канбану для верхнеуровневых расчётов сроков. В нормальных компаниях есть ротация менеджеров на проектах, поэтому желательно, чтобы все работали в одном и том же, или хотя бы совместимом софте. 
  • Уточнить, требуется ли пиэму логировать рабочее время, если нужно, то где именно, как часто и насколько подробно. Уточнить, логирует ли время команда и нужно ли вам валидировать таймрепорты. 
  • Уточнить, есть ли менеджерские планёрки, попросить добавить себя в эти встречи. Обычно они есть, частота зависит от того, насколько директор проектного офиса или операционный директор одиноки, от одного раза в неделю, до ежедневных. 
  • Уточнить, какое отношение в компании к юнит-тестам и автотестам, надо ли их учитывать в оценках. 
  • Уточнить, есть ли в компании запрет создавать задачи с оценкой больше определённого количества часов. Эта, на мой взгляд, очень неоднозначная политика, есть во многих организациях. 
  • Уточнить, обязательны ли репорты по результатам созвонов с заказчиком и кто именно их пишет. 
  • Уточнить, кого ставить в копию в письмах заказчику по проектам. 

Проектные вопросы

  • Выяснить, кто был вашим предшественником на проекте, пообщаться с ним. 
  • Выяснить контакты заказчиков, провести вводную беседу с ними, чтобы понять их верхнеуровневые приоритеты, цели проекта и глобальные ожидания. 
  • Узнать, как ведётся проект, водопадом или по гибким методологиям. 
  • Узнать, насколько системно в этой компании и на этом проекте построена работа с рисками. Принять решение, как будете работать с рисками вы. 
  • Узнать, как оплачиваются заказчиком работы: исходя из согласованной оценки или time/material. Чаще всего бывает первый вариант. Выяснить, с какой периодичностью оплачиваются работы. Выяснить, как часто и каким образом происходит сдача этапов, как проводятся демо. 
  • Выяснить, где лежит документация по проекту, в первую очередь, его паспорт или устав. Ознакомиться с этой документацией. В идеале, по проекту должно быть четыре вида документации: требования (функциональные и нефункциональные), техническая документация, тестовая документация, руководство пользователя. 
  • Выяснить, есть ли по данному проекту субподрядчики и фрилансеры, либо он делается целиком нашей командой. 
  • Выяснить, кто входит в команду проекта, как кого зовут, кто за что отвечает, у кого какая квалификация, кто техлид. Если каких-то специалистов не хватает, зафиксировать это. Потом можно будет потихоньку назначать 1:1 с каждым членом команды, чтобы познакомиться с ними поближе, но это не входит в первые шаги. 
  • Выяснить, что уже сделано по проекту, на какой он стадии. Что сдано заказчику, что не сдано, посмотреть акты приёмки. 
  • Выяснить, каким образом в этой компании принято делать оценку задач. Я писал пост обо всех способах оценить длительность задач проекта.
  • Заглянуть в таск-трекер (обычно это Jira), оценить, насколько аккуратно велись задачи по проекту, объединялись ли задачи под эпиками, писали ли члены команды комментарии, актуальны ли статусы, есть ли доска. 
  • Понять, как часто проводились синки с командой, запланировать эти синки в удобное для вас время с удобной для вас частотой.

Стратегические цели компании

Стратегические цели  

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

Выпустить продукт, чтобы что? Подсказываю:

  1. Чтобы стать самой инновационной компанией;
  2. Чтобы стать самой эффективной компанией. 

Совмещать можно, но у большинства компаний это плохо получается. Выбор одного варианта из этих двух работает лучше. Были случаи, когда компания переориентировалась, поменяв цель. Как Apple Джобса с Айвом и Apple Кука. Джобс выдавал инновационные продукты и менял мир. Иногда его продукты проваливались:

Спросом также не пользовались и вскоре были практически забыты Power Mac G4 Cube (выпущен в 2000 году, оказался дороже аналогов, производимых конкурентами Apple), телефон Motorola ROKR E1 (2005 год; не предсталял сбой ничего примечательного в качестве средство связи и был слаб в качестве плеера) и акустическая система iPod Hi-Fi (вышла в 2006 году; стоила дороже аналогичных продуктов конкурентов, но при этом предлагала меньшие возможности).

https://ria.ru/20111006/451127360.html

И вообще, Apple Джобса был не особенно финансово устойчив. Apple Тима Кука другой. Больше нет радикально новых продуктов, мир они больше не меняют, предпочитая перетасовывать функции существующих девайсов (например, чехарда портов у макбуков) и внедрять идеи, которые давно обкатаны у конкурентов (вроде извлечения текста из фотографии). Зато у компании растут выручка, прибыль и капитализация. Кук больше за второй подход. 

Мне бы очень хотелось изменить мир, но на практике приходится работать в компаниях второго типа, вытирая слёзы деньгами. Отчётливо помню, как пришёл на свою первую работу бизнес-аналитиком, принёс шефу идеи по улучшению продукта, а он мне в ответ: поисследуй, как эти функции реализованы в других приложениях. Твиттером пользуются 192 миллиона человек ежедневно, ясный перец, что эти люди привыкли к твиттерским решениям. Надо сделать как у них. Или как у Фейсбука. Или как у ещё кого-нибудь из могущественных продуктов. Мне это было странно слышать. Как же так, как мы изменим мир, если будем срисовывать функции у существующих продуктов? 

😈 А у компании была цель № 2. Гендир не хотел менять мир, он хотел, чтобы в каждом следующем квартале его акции стоили больше, чем в предыдущем. И большинство компаний такие. И работая в таких компаниях, я выработал подход 📈

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

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