Как устроен IT-проект

Задача в IT часто приходит одной фразой: «сделайте нам сайт», «добавьте оплату», «ускорьте отчёт». Из такой фразы не видно, зачем это нужно, кто будет пользоваться результатом и что нельзя нарушить, а именно от этого зависит, что в итоге получится. Разберём, из чего состоит IT-проект, чем он отличается от продукта, и какие вопросы помогают превратить такую фразу в задачу.

Кейс: «Сделайте нам сайт»

Владелец небольшого магазина «Узелок» говорит команде: «Хотим, чтобы заказы можно было оформлять через сайт. Нужно успеть к осеннему сезону». Звучит как готовая задача, но в ней много неясного.

Рисунок 1. Фраза владельца и три вопроса превращают её в паспорт проекта

Команда может сразу начать с каталога, корзины и оплаты. А может сначала выяснить три вещи: зачем это нужно, кто будет пользоваться результатом и в каких рамках работать. Ответы укладываются в один разговор, и от них зависит, с чего начинать и что в первую версию не войдёт. Итог разговора записывают в короткий документ, паспорт проекта (project charter, здесь в упрощённом виде), как на схеме.

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

Сначала «зачем»: цель

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

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

Рисунок 2. Цель с готовым решением и цель про проблему

Цель задаёт направление, но не говорит, для кого и с кем работать.

Потом «для кого»: участники

Второй вопрос: «Кто будет пользоваться результатом и кто принимает решения?» В первой фразе владелец назвал себя, но у результата будут и другие пользователи.

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

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

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

И «в каких рамках»: ограничения

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

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

Рисунок 3. Срок и ресурсы определяют объём первой версии: что входит и что уходит в следующий проект

Чем проект отличается от продукта

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

Слово	Что это	Бытовой пример	Пример «Узелка»
Продукт	Результат работы, которым пользуются люди и который живёт, пока нужен	Кафе на углу	Интернет-магазин «Узелок»
Проект	Временная работа со стартом и финишем	Ремонт в кафе	Запуск онлайн-заказов

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

Рисунок 4. Продукт на длинной шкале времени и два проекта внутри него

Где это встречается в работе

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

Итог

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

Что дальше

Здесь разобрано, какие вопросы задать. Как вести разговор, чтобы цель не осталась общей фразой, и как найти тех, кого заказчик не назвал, разбирают следующие статьи.

02-02. Бизнес-цель и заинтересованные стороны: как формулировать цель и находить тех, кто на неё влияет.
01-06. От идеи до релиза: какие этапы проходит задача после постановки.
01-03. Роли в IT-команде: кто входит в команду разработки и чем занимается каждый.

Источники

ГОСТ Р ИСО 21500-2023 «Управление проектами, программами и портфелями проектов. Контекст и основные понятия», термины «проект» и «заинтересованная сторона»: текст стандарта
PMI, PMBOK Guide: проект как временное усилие для создания уникального продукта, услуги или результата, в пересказе 4PMTI