Текст книги "Решебник начинающего руководителя проекта"

Кто все эти люди и как с ними работать?  Команда

У тебя появилась твоя команда. И это прекрасно.

Известная поговорка гласит: «Один в поле не воин». Полностью согласимся с тем, что проект надо делать командой. «Команда» изначально появилась как спортивный термин. В настоящий момент этот термин активно используется в корпоративном сегменте, а в проектном управлении уже закрепилось понятие «проектная команда».

Проектная команда отличается от простой группы специалистов наличием следующих вещей:

– общих целей;

– общих соблюдаемых правил;

– специализации (или выполняемых ролей);

– активного взаимодействия внутри.

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

С точки зрения управления надо каждого человека рассматривать в нескольких ипостасях:

1. Человек разумный. Человек как человек. Живет своей жизнью, у него свои интересы, свои проблемы, боли, здоровье, отношения со второй половиной. Он так же, как и ты, думает, что он будет есть на ужин и что по пути домой купить. Не забывай, что у него есть личная жизнь и часто она важнее, чем проект или вообще работа.

2. Человек командный. Представитель команды. Это специалист с компетенциями, на которые ты рассчитываешь. Этого человека рассматривают с точки зрения так называемых hard & soft skills. Т. е. что он знает, умеет и вообще насколько готов работать в команде.

3. Человек результативный. Можно сказать, результативность – одна из характеристик человека командного. Пусть так. Не будем спорить.

Обращай внимание на это качество, оценивая успехи команды и отдельных ее представителей. Бывают люди со слабыми soft & hard навыками, которые за счет усидчивости и упорства выдают результат даже бо́льший, чем «звезды». Возможно, при этом они делают ошибки, но они не высовываются и не рекламируют себя. Анализ фактических результатов показывает, что они молодцы. Опирайся на результативных людей.

Я специально выделил результат в отдельный аспект, чтобы обратить внимание на две крайности в людях:

a. Хороший человек. ТОЛЬКО «хороший человек». Это может быть друг/подруга, отличный добрый человек широкой эрудиции и искрометного юмора и вообще душа компании. Но бывает, что посмотришь на него с точки зрения результата, а там пустота. А если ты отбросишь эмоции, то обнаружишь, что проектные созвоны превращаются в веселые посиделки.

Так вот: хороший человек – это не профессия. И брат-сват-друг – тоже не профессия. Тебе же нужны профессионалы ради проектного результата?

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

«Хорошие» люди (в том смысле, в каком они описаны выше) постоянно тормозят проект, т. к. на них тратятся управленческие и временные ресурсы. Токсичные люди кратно повышают риски – ты понадеешься на них, и в ответственный момент они тебя подставят так или иначе. Могут сами потеряться, могут выбить полкоманды своим общением или что-то еще. Обычно лучше сделать чуть позже, но гарантированно и управляемо, а не уповать на то, что пронесет.

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

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

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

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

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

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

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

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

Если ты начинаешь проект со знакомыми людьми, то тебе проще: ты их уже знаешь. Ты можешь прикинуть, кто может «надломиться», где нужно постелить соломки, кого надо контролировать с точки зрения результата чуть ли не в ежедневном режиме.

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

Резюмируем:

– В твоей команде разные люди. В первую очередь они люди, а уже потом работники и коллеги.

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

– Оценивай людей по результату, это единственный ваш общий критерий измерения эффективности людей в проектной команде.

– Мотиваторы у всех разные – от денег и признания до новых навыков и причастности к великому результату. Ты должна эти мотиваторы знать.

– Если человек нерезультативен и/или его мотиваторы не могут быть обеспечены проектом, вам лучше с таким членом команды расстаться.

Как оценить работу и составить план?  Оценки, сроки и ресурсы

« – Есть ли у вас план, мистер Фикс?

– Есть ли у меня план? Да у меня целых три плана!»

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

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

Поэтому с точки зрения задачи есть два вида времени:

– Трудозатраты. Т. е. за сколько человеко-часов (человеко-дней и т. д.) можно выполнить ту или иную задачу.

– Срок реализации задачи. Это уже календарные или рабочие часы или дни.

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

1. Когда исполнитель сможет приступить к задаче?

2. Может ли таких исполнителей быть несколько? Это конкретные лица или любые члены команды (подходящие для задачи, разумеется)?

3. Выполнены ли все предварительные работы и задачи?

4. Есть ли элемент риска в задаче (риск ее внезапной остановки или увеличения трудозатрат)?

Например, реализация отдельной задачи займет 20 часов времени одного человека. Это оценка трудозатрат в часах.

У вас в команде есть человек, который может выделять по 8 часов в неделю (примерно по часу в основные рабочие дни после учебы и по 3 часа в выходные). Это доступный ресурс. Если он один, то срок рассчитывается просто:

Срок реализации = 20 / 8 = 2.5 недели.

Если у вас два человека, то не факт, что они сделают работу в два раза быстрее. Т. к. в этот момент появятся дополнительные трудозатраты на то, чтобы задачу поделить, договориться, где-то подождать друг друга, а потом объединить их результаты в общий результат (допустим, это принесет еще X затрат).

Они вдвоем смогут сделать эту задачу за 20 / (8*2) + Х трудозатрат, т. е. где-то недели за полторы или даже две, а не за 1.25. Где X будет нелинейно увеличиваться с добавлением каждого нового исполнителя задачи.

Факт, в котором прослеживается интересная аналогия: в каждом компьютере есть процессор, решающий задачи. Чем больше у процессора ядер, тем больше задач он может решать одномоментно. Так вот, производительность процессора при добавлении в него ядер растет нелинейно: каждое новое ядро дает все меньший прирост производительности – потому что часть ресурса тратится на синхронизацию работу ядер + растет общее энергопотребление всего процессора.

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

Вернемся к понятиям трудозатрат, ресурсов и сроков.

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

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

Давайте разделим в голове:

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

Например:

– анализ и составление требований (40 человеко-часов);

– разработка ПО (320 человеко-часов);

– тестирование (40 человеко-часов);

– развертывание и обучение (80 человеко-часов).

2. Дорожная карта – это планируемые бизнес-результаты и сроки.

Например:

– техническое задание – 10.04.24;

– дизайн ключевых экранов – 01.05.24;

– версия на DEV-окружение с полным функционалом и доступная для тестирования – 01.07.24;

– решение развернуто в промышленную эксплуатацию – 01.08.24.

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

Пара слов про понятие доступности ресурса.

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

– Говоря о финансовых ресурсах, важно понимать, что такое остатки/доходы/расходы. Может оказаться, что вы получите кассовые разрывы, т. е. вы должны будете потратить деньги, которых еще нет. Важно понимать, какой у вас приход, остаток и расход в каждый момент времени.

– Если говорим о физических ресурсах, таких как бетон, песок, дерево и т. д., то в сроках надо учесть не только стоимость, но и логистику. Достаточно ли их будет на момент старта задачи для ее реализации?

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

Резюмируем:

– Различай трудозатраты (объем) и сроки (время достижение результата).

– Срок – величина, рассчитанная на основе трудозатрат, ресурсов и календаря работы.

– Учитывай все, а не только доступные ресурсы. Сюда могут входить деньги, инструменты, инфраструктура, площади и т. д.

– Добавление нового человека в проект замедляет работу на первых этапах.

– Изучи методы и инструменты календарного планирования. Например, MS Project и диаграммы Ганта. Это полезно.

А мне за это заплатят?  Финансы и схемы работы

В начале любого проекта бывает сложно найти ответ на два вопроса:

– Просить денег или не просить, а если просить, то сколько? (с) Команда

– Платить или не платить, а если платить, то сколько? (с) Заказчик

Рано или поздно перед менеджером встает вопрос: «Вот мы собираемся работать, а нам за это заплатят? И если да, то сколько?» Давай разберемся, какие бывают схемы оплаты/монетизации работы и как они связаны с результатом.

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

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

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

Тут все просто:

– деньги платит инвестор, или вы сами можете выступить инвесторами;

– деньги платит заказчик.

В этих подходах есть фундаментальная разница.

В сфере IT можно выделить базовые схемы работы:

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

В этом случае вы создаете свой продукт. Свой в полном смысле слова. По сути, вы делаете стартап. Он ваш, он полностью и до последней точки кода принадлежит вам, и вы можете делать с ним, что захотите:

– вывести на рынок и предлагать всем или только тем, кто вам понравился. И зарабатывать на этом деньги;

– привлечь еще деньги от инвестора под обещания за эти инвестиции выдать какой-то результат;

– продать проект кому-нибудь со всем потрохами или подарить;

– закрыть (если договоритесь с инвестором).

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

– Продавать лицензии, например на количество пользователей, рабочих мест или объектов учета.

– Брать оплату по транзакциям. К примеру, по количеству действий в системе, по количеству записей и т. д. Обычно предлагают тарифные планы – от 0 до 1.000, от 1.000 до 5.000 и т. д.

– Продавать подписку за доступ к сервису. Например, на месяц.

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

– Поддержка. Ее тоже можно тарифицировать по-разному – закладывать в подписку, брать деньги за количество обращений и т. д.

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

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

Тут есть три базовые схемы работы:

– Fixed price.

Для начала вы пишете в том или ином виде Техническое задание (ТЗ), чтобы и вы, и заказчик понимали одинаково, «что есть результат». Затем вы оцениваете работы и выставляете сроки и стоимость.

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

Если компания занимается разработкой на заказ профессионально, то после проработки детального плана по всем работам дополнительно закладывается 15—20% рисков.

Если вы начинающая команда и можете оценить более-менее только разработку, то есть схема, разработанная одной большой ИТ-компанией с 25-летним стажем. Надо умножить оценку чистой разработки на π, т. е. на 3,14.

В случае, если вы не уложились в заявленные объемы работ, то вы сами виноваты и вам придется доделать все за свой счет. Обычно берется аванс в 20—50%, остальные деньги приходят уже после получения результата. Или по результатам выполнения этапов. В этом случае платят аванс в начале каждого этапа, а закрывающий платеж – в конце этапа после сдачи результатов работы. В рамках гарантийной поддержки бесплатно исправляются все найденные ошибки и несоответствия ТЗ.

Результат в такой схеме нужно интерпретировать как продукт, максимально соответствующий полному Техническому заданию. Обращаю внимание, не самый красивый или удобный для пользователя, а именно максимально соответствующий ТЗ. Именно в этом сила и слабость Fixed price. С одной стороны, все не предусмотреть, с другой – заказчик максимально продумывает, прописывает и подписывает требования к конечному результату. Вот к нему и стремишься.

Из плюсов для заказчика – цена зафиксирована, и больше он точно не потратит. Из минусов – зафиксированы и Технические требования. Т. е. заказчик должен заранее все продумать досконально, а разработчик может делать как в ТЗ, а не как потом оказалось надо заказчику. Изменились требования? Можно и нужно пересмотреть цену.

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

– Time & Material.

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

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

Оплата производится периодически: раз в неделю, в две, ежемесячно, да хоть каждый день. Здесь ключевой фактор: способность выдавать с той же частотой и результаты. Нужно понимать, что для любой компании лучше/безопаснее получать расчет за работы чаще, чем «подвешивать» сделанную работу на недели и месяцы, пока не будет выполнен расчет. Могут возникать кассовые разрывы и просто прямые финансовые риски: а вдруг заказчик не сможет / не захочет оплачивать очередной результат?

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

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

В этой схеме для менеджера результатом становится качественная и частая поставка новой функциональности. То есть нужно делать очень полезные вещи (см. «Стартап») и при этом попадать в ожидания по срокам (см. «Fixed price») на коротком горизонте в 1—2 спринта. Основные акценты в работе: прозрачность работы, регулярные совместные пересмотры планов, приоритетов и требований, регулярная поставка результата и скорость. Постоянная шлифовка на ходу часто приводит к существенному увеличению сроков, а об этом заказчик забывает.

– Outstaff

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

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

Стоимость человеко-часа в этом случае чуть ниже, чем в Time & Material, т. к. все риски лежат на заказчике.

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

Несколько слов, как посчитать деньги, которые хочется и можно выставить. Есть три варианта на старте:

1. По себестоимости.

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

2. По рынку. Смотрите аналоги и предлагаемые решения и берете среднюю цену.

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

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

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

Итого:

– Есть разные схемы финансирования проекта.

– В зависимости от схемы радикально меняется понятие результата и ключевые риски для команды.

– Менеджер проекта в каждой из схем выделяет свои ключевые обязанности:

1. В разработке на деньги инвестора – это быстрая результативность в деньгах или пользователях/подписчиках.

2. В Fixed price – выдать результат в жестких границах и управление изменениями.

3. В Time & Material – частый и качественный результат, прозрачность, частые изменения.

4. Outstaff – четкое исполнение профессиональных функций.