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

запихиваем проекты в треугольники

Тег: менеджмент

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

forming, storming, norming, performing  

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

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

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

Forming

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

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

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

Storming

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

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

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

Norming

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

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

Performing

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

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

Adjourning

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

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

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

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

О профессиональном выгорании

Профессиональное выгорание  

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

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

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

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

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

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

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

(далее…)

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

 

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

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

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

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

Софт менеджера IT-проектов

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

Несколько слов о конфигурации компьютера:

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

Также при покупке этого компа мне казалось, что 256 гигов SSD — это тоже очень мало, но если отказаться от привычки складировать на диске всякий варез, который нужен раз в пятилетку, выделив под него внешние HDD, места вполне хватает.

«Флешечкой» называется MicroSD на 64 гига, постоянно вставленная в разъём для SD-карт при помощи специального пенальчика Nifty MiniDrive Retina. Выглядит это так:

Nifty MiniDrive Retina

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

С железом всё, переходим к софту.

Общение

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

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

На моей текущей работе используется домен Exchange и в качестве болталки принят Teams. Плюсы — вполне прилично реализованные групповые звонки с возможностью записи в мелкомягкое облако, удобный календарь, глубокая интеграция с Microsoft Office. Интеграция с доменом позволяет обратиться к любому сотруднику компании, зная его ФИО. Однако я каждый день плююсь с Teams из-за того, что с нами работает внешняя команда, имейлы сотрудников которой приходится, создавая встречи, копипастить. Хранить внешние имейлы, видимо, никак невозможно. Кроме того, я так и не понял, как окончательно стереть учётную запись с предыдущей работы. В общем, из клиента «торчат нитки», но общаться в нём вполне реально.

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

В качестве почтового клиента пробовал использовать AirMail, но в итоге вернулся на стандартный маковский клиент. Он поддерживает практически любые почтовые учётки, весьма минималистичен и удобен в работе. Больше всего мне нравится помечать цепочки писем флажками разного цветов. Недостатки — при попытке добавить собеседника в маковский контакт-лист ничего не происходит. Кроме того, если вам пульнут длинную переписку с длинной историей, разобраться в ней будет сложно. А ещё, я так и не разобрался, как автосортировать почту средствами этого клиента, использую сортировку Google в лично почте и средства Outlook в рабочей.

Руководство рассматривает Skype for Business в качестве альтернативы Teams, но с этой санкционной истерией вполне может прийтись перейти на какой-нибудь Агент.Мейлру

Альтернативы:

«Телемост» от «Яндекса» позволяет записывать разговоры и принимать до 40 человек, еще и с десктопным приложением. Может быть интересен тем, кто пользуется «Трекером» или другими частями экосистемы «Яндекса».

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

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

https://rb.ru/opinion/jira-and-teams/

Менеджеры задач

Задачники можно разделить на условно командные и условно личные. Начнём с командных.

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

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

Встречал попытки использовать Trello, но он, будучи хорошим личным задачником, в группе работает плохо, недостаёт функций, плагины могут далеко не всё. А ещё, автозамена всё время норовит заменить «трелло» на «трепло». В реальной практике управления отделом с канбаном я заменил его на Kanbanize, там хотя бы свимлайны есть.

Альтернативы:

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

Megaplan — довольно старая (в хорошем смысле) и известная система, начинавшаяся как CRM и заточенная под российский бизнес (51% компании принадлежит 1С, что о чем-то говорит). По имеющейся у нас информации, неплохо покрывает потребности бизнеса как CRM и трекер, но без фокуса на ИТ. Пользователи критикуют медленную поддержку и долгие/дорогие доработки, которые всегда требуются коробочным версиям.

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

https://rb.ru/opinion/jira-and-teams/

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

Рабочий лист задач я вам не покажу, а вот проект с идеями для постов — пожалуйста:

Todoist

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

Ещё он умеет автоматически импортировать встречи из гуглокалендаря и превращать их в задачи. К сожалению, календарь Exchange ему импортнуть не под силу. Приложение для андроида полнофункциональное.

(далее…)

О словаре терминов

 

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

Задача этого словаря — сделать так, чтобы одни и те же вещи назывались в разных командах одними и теми же словами и наоборот, чтобы одни и те же слова означали одни и те же объекты и процессы.

Только не делайте из словаря карго-культ, не надо записывать туда git, dns и https, только специфичные для вашей предметной области термины.

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

Уважение  

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

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

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

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

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

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

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

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

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

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

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

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

Критика

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

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

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

 

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

Тиран

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

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

Демократ

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

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

Рукастый

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

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

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

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

Жертва

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

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

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

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

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

Невидимка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О безответственных сотрудниках

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

Сотрудник, который работает в компании достаточно давно, получает от вас поручение и сразу начинает заваливать сотней вопросов. Где взять то, где взять это, кого лучше под это зарекрутировать, где найти ресурсы. Это нормально для самого первого, второго, третьего поручения в компании, да, его надо погрузить. Но вот когда так на поручения реагирует погружённый сотрудник, это сигнал. Ответственный задаст только ключевые вопросы, а менее существенные детали решит на своё усмотрение. Попробуйте на бесконечный поток вопросов отвечать в стиле корпоративных психологов: «А сам ты как думаешь?», это помогает.

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

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