Постановка целей в IT-проекте — это процесс, который переводит «хотим как у Тинькофф, только за три недели» в измеримые цели it-проекта, критерии успеха и конкретные задачи в Jira/Yandex Tracker, чтобы команда понимала, что делать, а бизнес — за что платит.

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

Ниже — 7 шагов, как ставить цели так, чтобы они связывались с задачами и выживали в реальности: бюджет, сроки, 1С, интеграции, безопасность, капризный заказчик и «а можно ещё маленькую кнопочку».

7 шагов постановки целей: от «хочу» к задачам

Шаг 1. Сформулируйте бизнес-цель человеческим языком (а не “сделать систему”)

Тезис: цель it-проекта должна описывать изменение в бизнесе, а не факт разработки.

Как выглядит плохо: «Разработать личный кабинет клиента», «Внедрить CRM», «Сделать мобильное приложение».

Как выглядит нормально: «Сократить время обработки заявки с 2 дней до 2 часов», «Увеличить конверсию оплаты на сайте на 10%», «Снизить нагрузку на колл-центр на 15% через самообслуживание».

Практический вывод: если цель можно выполнить, ничего не улучшив (просто “выпустили релиз”) — это не цель, это активность.

Подводный камень: «цифры потом придумаем». Потом обычно наступает “поздно”: продукт уже в проде, а пользователь всё равно работает через Excel.

Шаг 2. Опишите пользователя и сценарий, иначе вы оптимизируете фантазию

Тезис: постановка целей без конкретного пользователя превращается в «сделаем красиво».

• Кто пользователь: клиент, оператор, бухгалтер, кладовщик, менеджер.
• В каком процессе боль: оформление, оплата, возврат, согласование, отгрузка.
• Что мешает: лишние шаги, ошибки, ожидание, ручной ввод, двойные системы (например, 1С + самописка).

Практический вывод: цель должна быть привязана к сценарию: «клиент оплачивает без звонка», «оператор закрывает тикет за 3 минуты», «согласование договора — за 1 день, а не за 7».

Подводный камень: «пользователь = директор». Директор пользователь ровно до момента демо. Потом страдает операционист.

Шаг 3. Зафиксируйте метрики успеха (и одну метрику “не сломать”)

Тезис: как ставить цели без метрик — никак. Иначе спор “получилось/не получилось” будет решаться громкостью голоса.

Метрика “не сломать” — это ограничение: например, «ускоряем выдачу кредита, но не ухудшаем процент дефолта» или «снижаем шаги оформления, но не падаем по антифроду».

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

Шаг 4. Привяжите цель к ограничениям: срок, бюджет, комплаенс, интеграции

Тезис: реальная цель it-проекта всегда живёт в треугольнике «объём—срок—стоимость» плюс российские реалии: ГОСТы, ФЗ-152, импортозамещение, интеграции с 1С и госплатформами.

• Срок: к какой дате должно заработать, и почему (сезон, аудит, штрафы, контракт).
• Бюджет: хотя бы диапазон, иначе план будет “на бесконечность”.
• Интеграции: 1С, ЭДО (Диадок/СБИС), SMS/почта, банковские API, Госуслуги (если вдруг), внутренние шины.
• Безопасность: персональные данные, доступы, журналирование.

Практический вывод: ограничения — не “помехи”, а часть постановки целей. Если их не записали, они всё равно придут. Просто позже и злее.

Подводный камень: «интеграция потом». Потом выясняется, что в 1С нет нужного справочника, а у подрядчика на это “не было оценки”.

Шаг 5. Сделайте декомпозицию: цель → результаты → фичи → задачи

Тезис: цель должна раскладываться до уровня задач, которые можно взять в спринт.

1. Цель: сократить время обработки заявки с 48 часов до 6 часов.
2. Результаты (outcomes): меньше ручного ввода, меньше ожидания согласования.
3. Фичи (outputs): автоподтягивание данных из 1С, шаблоны решений, очередь задач, уведомления.
4. Задачи: API-метод, форма, роли доступа, миграция данных, автотесты, мониторинг.

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

Подводный камень: фичи появляются как грибы, а приоритета нет. Потом «мы всё сделали, но цель не достигли» — классика.

Шаг 6. Назначьте владельца цели и правила принятия решений

Тезис: у цели должен быть владелец (обычно бизнес), а у задач — ответственные (обычно IT). Иначе будет “коллективная ответственность”, то есть ничья.

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

Шаг 7. Проведите “проверку на реальность”: риски, план B и контрольные точки

Тезис: хорошая постановка целей включает способ понять на 20–30% пути, что вы идёте не туда.

• Контрольные точки: пилот на одном филиале, A/B на части трафика, ограниченный релиз.
• Риски: зависимость от 1С, качество данных, сопротивление пользователей, безопасность, производительность.
• План B: что делаем, если метрика не растёт (меняем сценарий, убираем шаг, докручиваем обучение, откатываем).

Практический вывод: цель — это не плакат. Это гипотеза, которую вы проверяете релизами.

Подводный камень: релиз без измерений. Тогда вы как пилот без приборов: летите бодро, куда — выяснится при посадке.

Экспертный вердикт и инструмент: чек-лист “связь цели и задач”

• Цель описывает бизнес-эффект? Не “внедрить CRM”, а “увеличить долю повторных продаж на X%”.
• Есть пользователь и сценарий? Кто делает что и где болит.
• Есть метрика успеха и метрика-ограничение? Чтобы не “улучшить” одно, сломав другое.
• Есть источник данных? Где меряем, кто отвечает за доступ к данным.
• Цель декомпозирована до задач? Outcomes → фичи → задачи, а не “список хотелок”.
• Определён владелец цели? Один человек, не чат “все заинтересованные”.
• Есть контрольные точки и план B? Как поймём, что не взлетает, и что делаем.

Если вы сменяете профессию и метите в аналитику/PM/PO — умение делать такую постановку целей ценится выше, чем знание очередного модного фреймворка. А если вы разработчик — это шанс стать тем, кто не просто выполняет задачи, а влияет на приоритеты. На собеседованиях это конвертируется в деньги быстрее, чем “я прочитал книжку про Scrum”.

Частые вопросы