Как планировать проект. Управление изменениями IT-проекта

Введение

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

Мы поговорим о планировании возможностей будущего продукта, неверных шагах, заблуждениях, которые вы можете упустить при проработке своего веб-проекта. Это можно отнести к любому IT-проекту: создание сайта, мобильного приложения, программы и др.

Точная ближайшая версия продукта и общие планы по продукту

Часто заказчик хочет досконально описать громадный продукт в самом первом техническом задании (ТЗ), т.е. учесть все-все требования, которые могут потребоваться в проекте в дальнейшем.

Это плохой подход для большинства проектов по следующим причинам:

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

Альтернативный подход:

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

Такой подход снижает риски продукта (сделать что-то не то, перерасход проекта), снижает стоимость внедрения 1 версии, ускоряет получение обратной связи по продукту.

Учитывайте свой масштаб

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

Необходимо хорошо просчитывать свои возможности.

Проект - это не спринт, а марафон.

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

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

Что это значит на практике?

Умерьте свой аппетит. Делайте продукт меньше по объему. Не играйте в "больших дядей", где проект может годами не окупать себя и жить за счет внешних дотаций.

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

В проекте с неясным результатом нет фиксированных бюджета и сроков

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

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

Конечно, нужно в любом случае иметь какие-то начальные оценки, но надо относиться к ним именно как к оценкам, а не фактам.

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

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

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

Передача информации через документы, а не на словах

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

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

А затем просто давать всем заинтересованным лицам для обсуждения.

Средства типа Google Disk позволяют совместно работать над документом, комментировать. Это делает проработку глубже и полезнее, нежели обсуждение на пальцах общих моментов по телефону.

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

Варьировать параметры бюджет, объем, сроки

В проекте есть 3 составляющие, которые завязаны друг на друга: объем работ, сроки, бюджет. Если изменить что-то одно, то меняются и другие параметры.

• Хотим больше возможностей в проекте - вырастет бюджет и сроки.
• Хотим ускориться - можно увеличить бюджет на премии за скорость.
• Хотим снизить затраты - можно что-то выкинуть из планируемой версии.

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

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

Гораздо лучше ускорять проект, снижать бюджет за счет правильного снижения объема работ. Многие элементы в проекте можно сделать проще (но на том же уровне качества), какие-то моменты можно вообще не делать в проекте. 

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

Закладывать ресурсы на переделки, оставить пространство для маневра

В проекте нельзя планировать точь-в-точь. В любом проекте есть неопределенность, и эта неопределенность потребует затрат.

Всегда нужен некий запас прочности для закрытия этих неопределенностей.

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

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

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

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

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

Так как вести учет возможностей платформы.

Для этих целей можно использовать беклог. По сути это просто Excel таблица с полями: Требования, Приоритет, Сложность, Статус, Этап.

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

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

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

Ведение общего беклога продукта - прерогатива владельца продукта. Именно он должен вдумчиво, с пониманием деталей определять состав и направление развития продукта.

Разведка боем

Бывают такие возможности в продукте, которые сложно сразу определить, детализировать, понять, как к ним подступиться.

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

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

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

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

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

Сотрудничество с подрядчиками, а не противостояние

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

Имеет ли право так делать заказчик. Конечно имеет, он же платит в проекте. Ему нужен результат, и он достигает его через эти методы.

Но подумайте о другой стороне этого вопроса.

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

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

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

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

Как построить сотрудничество с исполнителями:

• работа строго по ТЗ. Чем строже подход, тем меньше поводов для недопонимания и конфликтов
• уважать интересы своих партнеров. Не пытаться прогибать партнера. Партнер - не дурак, он все это видит и понимает. А если партнер дурак, то в пору задуматься о своем бизнес-окружении.
• выполнять свои обязательства максимально точно и оперативно. Чем более прогнозируем партнер (без фокусов), тем проще с такими людьми работать.
• уважение, вежливость, доброжелательность. Доброжелательность (настоящая, искренняя, а не из клеенки) - это простой способ сгладить в острых, спорных вопросах, которые встречаются в любом проекте.

Заключение

Мы рассмотрели управление веб проектами в некоторых аспектах, точнее в части общего планирования задач по проекту.

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

Если говорить кратко об управление веб проектами:

• определить видение продукта;
• написать общий контурный план движения по продукту;
• определить минимальную первую версию продукта;
• запустить, шлифовать, итеративно развивать продукт.

Насколько полезной была статья?