Меня зовут Настя, я Unit Manager международной команды в компании Itransition и тренер по управлению проектами в IT-Academy. За почти 10 лет опыта в менеджменте мне довелось поработать с разными заказчиками, продуктами, командами. На старте карьеры меня удивляло, что, согласно статистике PMI, из года в год более половины проектов заканчиваются крахом.
Сейчас я охотно верю этим данным, ведь сколько IT-проектов я ни стартовала, не было ни одного, чтобы все шло идеально. Я также не знаю ни одного практикующего менеджера, у которого бы всегда все шло как по маслу (те, с кем я познакомилась на собеседованиях, не считаются). Как ни печально, многих трудностей можно было бы достаточно легко избежать, или, как минимум, облегчить ход развития событий, предприняв определенные шаги на самом старте проекта.
В данной статье речь пойдет о тех практиках и артефактах, на которые я обращаю особое внимание на старте проекта. Информация будет полезна не только начинающим, но и менеджерам с опытом работы на IT-проектах: для опытных менеджеров примеры будут более понятными, а новички, надеюсь, смогут избежать подобных сложностей в начале карьеры.
Я расскажу как об известных и достаточно банальных, но очень полезных вещах, так и том, чего не встретишь как минимум в первых пяти статьях google на тему «как стартовать проект».
О чем мало говорят, но было бы полезно использовать
Team Charter или манифест команды
Было ли у вас когда-нибудь ощущение, что вы работаете в коллективе, но не команде? У меня было много раз, к сожалению. Первым шагом на пути создания команды я чаще всего выбираю Team Charter. Мне очень нравится этот инструмент, так как он решает сразу несколько задач. При этом важен не только процесс создания манифеста/устава команды, но и получившийся артефакт.
Во-первых, Team Charter позволяет выровнять контекст и узнать о ролях в команде и целях проекта. С командой редко разговаривают о таких вещах, хотя усилий это требует совсем небольших, а эффект от искренней вовлеченности в работу и отсутствия лишних коммуникаций и ложных ожиданий может превзойти все ожидания.
Во-вторых, манифест устанавливает понятные и прозрачные правила игры, что снижает общий уровень тревожности. Старт нового проекта, как и любое изменение, - всегда стресс для всех вовлеченных ввиду большого количества неопределенности. Да, тревожно не только менеджеру. Мы не знаем, как нас примут в новом коллективе, какое поведение здесь поощряется и каким ценностям следуют.
Неопределенность создает психологическое напряжение и страх ошибки, за которым стоит страх непринятия. Это очень глубокая тема, но не хотелось бы уходить в сторону от старта проектов. Поэтому всем заинтересовавшимся рекомендую почитать труды или посмотреть видео Эми Эдмондсон, одного из ведущих исследователей психологической безопасности на рабочем месте.
В-третьих, манифест сокращает время на адаптацию новичков. Так или иначе, мы не застрахованы от смены членов команды. В таком случае манифест даст новичку информацию о том, в какую группу людей он попал, зачем и по каким правилам эта группа существует.
Onboarding Guide или руководство для новичков
Продолжая тему смены членов команды, весьма полезным будет начать создавать руководство по онбордингу для новичков с самого старта проекта. Первое время оно будет служить описанием рутинных процессов (описание проекта, отпуска, больничные, трекинг времени, тимбилдинги, манифест и т.д.) для всех членов команды.
А затем, когда команда привыкнет к этим правилам, гайд станет надежной опорой для каждого новичка. В противном случае вам придется всю эту информацию пересказывать из уст в уста, тратить на этот процесс много времени и встречать досадные неприятности из-за того, что какая-то информация все же потерялась.
Communication plan или план коммуникации
На просторах глобальной сети можно найти великое множество разнообразных шаблонов плана коммуникаций, поэтому будет небольшим лукавством сказать, что о нем мало говорят. Но говорят обычно не предметно, а скорее слишком теоретически. Я считаю этот инструмент крайне полезным, поэтому поделюсь, как я его использую в своей практике.
Обычно создаю на Confluence страницу под названием Communication plan, где располагается таблица. Ее верхняя строка представляет собой таймлайн - схему рабочей недели или месяца (зависит от продолжительности итераций, по которым выстраиваются рабочие процессы). Следующие строки посвящены инструментам коммуникации, обычно это встречи и разного рода отчеты.
Остается только отметить на таймлайне, какие из этих инструментов будут использованы и когда. Это позволяет увидеть, насколько равномерно распределены встречи, нет ли нагромождений из митингов и перерасхода времени на коммуникацию. Таблицу можно дополнять различными деталями и ссылками, а также обязательными и необязательными участниками. То же самое можно сделать в отдельном календаре Outlook, не всем удобно размещать напоминания об отчетах в этом инструменте в качестве события.
Реестр юридических документов
Здесь все просто: чтобы ничего важного не потерять и не забыть, лучше сразу все хранить в одном месте, будь то папка на Sharepoint или страничка на Confluence. Важно помечать «срок годности», чтобы вовремя обновлять необходимые документы.
Это позволит избежать ситуации, когда команда отработала очередной месяц, клиент внезапно перестал платить по счетам, а документы по оказанию услуг уже просрочены и подписывать снова их никто не собирается – средства закончились.
О чем многие знают, но часто забывают
Договор
Что является отправной точкой для старта проекта? В сервисных IT-компаниях, как правило, – подписание контракта. Но почему-то этот самый контракт менеджеры не считают нужным прочитать. Постараюсь кратко описать, что полезного там можно найти, помимо всем известных сроков и стоимости поставки:
Deliverables или объем поставляемых услуг
Сюда, бывает, не заглядывают до самого окончания проекта - и потом находят много интересного. В объем поставки, помимо кода, может входить различная документация и дополнительные услуги. Зная о таких нюансах, можно все эти артефакты подготовить заранее, в спокойном режиме.
К примеру, на одном из проектов в комплект поставки должны были входить требования в виде спецификации. Но, не обратив на это внимание, команда работала над требованиями только в виде описания Jira-тикетов. Благо, все закончилось мирно и заказчику этого оказалось достаточно, но для этого менеджеру на пару с бизнес-аналитиком пришлось приложить немало усилий.
Assumptions или допущения
Допущения, обычно, формируются на этапе оценки проекта, но не всегда оправдываются, хоть и влияют на оценку проекта. С другой стороны, зачастую assumptions - это оплот надежды менеджера не остаться крайним, когда все идет наперекосяк по каким-то внешним причинам. Допущения позволяют вести переговоры с заказчиком не с позиции оправдывающегося, а на равных. С другой стороны, допущения тесно связаны с рисками и дают нам фору в борьбе с обстоятельствами.
Например, в допущениях указано, что заказчик предоставит готовые API для разработки front-end. Соответственно, есть риск того, что это допущение окажется ошибочным. В таком случае команде придется, как минимум, приложить дополнительные усилия на интеграцию с серверной частью приложения. Задача менеджера – определить, насколько сильным будет влияние на проект риска, что допущение окажется ошибочным, и составить план «Б».
Процедура приемки
Даже когда проект идет прекрасно, команда счастлива, а заказчик вас боготворит, все может измениться на этапе приемки. Поверьте, когда вы распустите команду, ваш бэклог будет полон минорных багов, а заказчик откажется принимать проект, пока все не пофиксят, вы вспомните об этом пункте договора. Если в договоре явным образом не указывается уровень качества поставляемого программного обеспечения, обязательно внесите пункт «согласовать стратегию тестирования с заказчиком» в свой чек-лист по старту проекта.
В этом же пункте обычно описываются отчеты, которые исполнитель обязан предоставлять заказчику, а также порядок приемки этих отчетов. В данном случае не рекомендую действовать исключительно «по букве закона» и спать спокойно, если заказчик не ответил на ваше письмо с проблемным отчетом в течение оговоренного срока. Обычно это означает, что существует риск «нарваться» на еще большие проблемы и непонимание заказчика в будущем, хотя, согласно договору, отчет и считается принятым.
Я указала только три пункта, но договор нужно и важно читать полностью, вдумчиво! На моей практике были примеры, когда менеджер обещал клиенту гарантию, руководствуясь своим опытом работы с контрактами в другой компании, хотя в текущем контракте она не была прописана. Бывало, что осуществляли замену членов команды, не соблюдая условия договора, что влекло за собой праведный гнев заказчика. А ведь можно было этого легко избежать.
Устав проекта
Я очень часто слышала, что устав – это атавизм, он никому не нужен и ценности никакой не несет. Но договор доступен далеко не всей команде, а альтернативного артефакта, где указана вся основная информация о проекте, пока не придумали. Устав проекта совершенно не обязательно должен быть официальным документом – достаточно аккуратной странички на Confluence или Wiki со всеми необходимыми ссылками.
Даже если вы работаете по типу контракта dedicated team, устав заставит вас задуматься, чего же на самом деле хотят ваши стейкхолдеры. Такие мысли, подкрепленные конкретными действиями, переводят вас из разряда администраторов в управленцев. На мой взгляд, устав, как предмет гигиены, как заглавие книги, должен быть у любого проекта.
Kick-off Meeting или встреча по инициации проекта
Я бы сравнила kick-off с первым свиданием: от того, как пройдет первое, во многом зависит, будет ли продолжение. Да, отношения с заказчиком подкреплены договором, но никто не застрахован от эскалации и просьбы сменить менеджера. Только вот почему-то далеко не всегда к kick-off готовятся так же трепетно, как к первому свиданию. Я не буду говорить про повестку встречи, но вот на что я рекомендую обратить внимание:
Подготовьтесь и проведите внутренний kick-off. Это позволит вам отрепетировать звонок с заказчиком, пообщаться с командой, с pre-sales, собрать всю возможную информацию и создать список открытых вопросов. Как результат, вы будете более подготовленными и менее тревожными.
Подготовьте презентацию. Она сильно облегчит вам задачу как докладчику и позволит всем участникам встречи легче улавливать информацию, быть всегда в одном контексте. Инструментов для этого достаточно: Microsoft Power Point, Miro, Prezi – выбор на любой вкус.
Убедитесь, что у всех участников с вашей стороны включены камеры, налажен звук микрофона, всех хорошо видно, у всех надлежащий внешний вид. Созвонитесь за 30 минут до звонка с клиентом, чтобы все проверить. Все уже привыкли к условиям удаленки, поэтому если вдруг на заднем плане у кого-то появится кот или ребенок – это не страшно. Страшно, если вы начнете вести себя неадекватно и кричать на ребенка или кота.
Предупредите клиента о формате звонка. Обычно я высылаю презентацию заранее, чтобы он смог подготовиться, а также внести дополнения или правки при необходимости.
Вышлите follow-up и приглашения на последующие встречи. Если вы не задокументируете ваши договоренности - будьте уверены: о них забудут или, что хуже, в момент наступления проблем будут использовать не в вашу пользу.
Я видела проекты, на которых не было ни внутреннего, ни внешнего kick-off. Также видела проекты, где kick-off проходил без презентаций и качественной подготовки. Они не закрывались, но, помимо налета безразличия со стороны менеджмента, появлялись другие, более серьезные проблемы.
Например, не было выявлено, что клиент не знаком с методологией Scrum и просто не понимает роль владельца продукта, которой его «наградил» менеджер. Или выявлялись критические расхождения в понимании уровня прозрачности процессов разработки, в результате чего появлялись эскалации.
Заключение
Пока писала статью, несколько раз ловила себя за руку, чтобы не углубиться в какую-то из вышеупомянутых тем. Хоть это далеко не все, что входит в работу менеджера в начале проекта. Надеюсь, список получился полезным и поможет вам избежать некоторых трудностей с самого старта. Все эти инструменты не панацея, главное – понимать, в чем их польза и зачем менеджеру их использовать. Если вам есть чем поделиться по этой теме, буду рада обсудить в комментариях!
