Предварительная оценка проекта

В начале работы над ИТ-проектом, как правило, проводят оценку. Её отсутствие или неточность может сформировать неправильные ожидания по срокам и бюджету проекта.

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

Актуальные методы оценки ИТ-проекта

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

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

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

Такой подход позволяет учесть все необходимые работы и подобрать оптимальный состав команды специалистов. Сроки выполнения предварительной оценки методом по фичам зависят от особенностей проекта: для стандартного приложения – до 8 часов при условии одновременного проведения оценки всеми экспертами сразу. Но в этом процессе могут участвовать специалисты нескольких направлений, поэтому в среднем предварительная оценка занимает 3-5 дней.

Есть два общепринятых варианта подсчета трудозатрат:

1. диапазонный метод (от X до Y часов), когда оценщик на основании своего опыта дает пессимистические и оптимистические данные по трудозатратам на фичу,
2. метод PERT – расчет выполняется по трем точкам:

где to – оптимистическое время – минимально возможная длительность выполнения задачи, tp – пессимистическое время – максимально возможная длительность выполнения задачи, tm – наиболее вероятное время – наиболее вероятная длительность выполнения задачи, te – ожидаемое время – оценка длительности выполнения задачи на основе оценок оптимистического, пессимистического и наиболее вероятного времени.

Этапы предварительной оценки

Отправляя заявку в ИТ-компанию, заказчик обычно преследует одну из целей:

1. Просит оценить проект «под ключ». У него может быть определен объем задач и разработано техническое задание (ТЗ) или только объем задач без ТЗ.
2. Хочет узнать, что можно сделать в рамках определенного бюджета или в конкретные сроки.

1 этап

Чтобы выяснить все детали по проекту, специалист компании (обычно сотрудник отдела продаж) организует созвон с клиентом. Один из способов получить необходимые для предварительной оценки данные – вместе с клиентом заполнить бриф и ответить на ключевые вопросы о будущем ИТ-продукте. Но обычно беседа с клиентом проходит в свободной форме. Это позволяет выявить действительно важные для него и его бизнеса аспекты.

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

На этом этапе формируются ответы на ключевые вопросы:

• Границы разработки – какие этапы работы нужно оценить (и в перспективе выполнить), а какие клиент берет на себя?
• Какие направления разработки стоит подключить к оценке?
• Какой стек будет предпочтителен? Что еще нужно заложить в оценку? Например, клиент решает, что дизайн будет разрабатывать сам. Значит, в оценку нужно включить время на приемку дизайна заказчика – проверить, соответствует ли дизайн функционалу системы.

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

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

2 этап

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

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

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

Например: оценка разработки одной фичи не должна превышать 8 (в крайнем случае - 16) часов, а диапазон разброса минимальных и максимальных значений не должен превышать 40%. В ином случае возможен высокий уровень неопределенности в реализации фичи, что может привести к увеличению рисков проекта. Также есть обязательное требование, чтобы оценщик зафиксировал в комментариях, как он видит реализацию задачи за указанное время. После того, как все оценщики завершили свою часть работы, проводится проверка оценки. Далее готовится описание и на основе сметы – примерный состав будущей команды ИТ-проекта, сроки реализации или roadmap. Для достижения качественных результатов подбирается слаженная команда с экспертизой в конкретной отрасли и опытом совместного решения задач.

Декомпозиция

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

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

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

Основные подходы и правила декомпозиции

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

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

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

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

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

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

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

Способы декомпозиции

Несколько потребностей

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

Сценарии использования

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

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

Операции (CRUD)

Это, наверное, самый распространенный способ декомпозиции. Здесь задачи деляться по операциям Create, Read, Update и Delete. Он подходит для задач, где нужно чем-то управлять или что-то конфигурировать. Например, задача по оформлению заказа делится на четыре более мелкие: создание заказа, его просмотр, редактирование и удаление.

Варианты интерфейса

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

Разделение по ролям

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

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

Обработка ошибок

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

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

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

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

Статические, затем динамические

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

Производительность

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

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

Возможные трудности

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

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

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

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

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

Ссылки

• Как справиться с декомпозицией задач и не перестараться