Два способа подготовить ТЗ для разработчиков

Два способа подготовить ТЗ для разработчиков

Больше привязки к финдиру

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

Когда мы говорим о внедрении IT-систем, у нас есть два способа их интегрировать: классический и Agile*. Соответственно может быть два разных ТЗ в зависимости от способа. В этом уроке вы узнаете, как подобрать подходящую модель внедрения IT-системы и что учитывать при формировании ТЗ.

*Agile – гибкая система управления проектами.

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

Обычно в процессе внедрения IT-систем бывает масса корректировок, замечаний и дополнений. При стандартном планировании это влечет за собой полной изменение плана и удлинение сроков, потому что поправки не предусмотрены заранее.

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

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

Если мы говорим о ERP-системах, тот же SAP лучше внедрять именно так. SAP – огромная тяжелая машина с модулями, которые взаимосвязаны между собой. Тут Agile скорее вреден. Лучше идти стандартным путем и не придумывать новых механизмов.

Стандартизированное внедрение требует качественного ТЗ и подробного плана, где прописаны все риски. Правильнее всего попросить интеграторов, которые участвуют прописать драфт ТЗ или даже реальное ТЗ еще на этапе тендера.

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

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

Модель внедрения по Agile

Подобный подход лучше работает, когда речь идет о более утилитарных и маленьких системах, типа BI. Потому что заказчик обычно не знает заранее, что именно ему нужно. Иногда это понимание приходит только, когда процесс внедрения уже заканчивается. Этот риск хорошо нивелирует Agile-методика. Например, я мало встречал людей, которые идеально и досконально понимают, какая бюджетная модель им нужна. (пояснить)

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

В модели внедрения по Agile есть два основных этапа.

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

2. Производство — мы планируем встречи заказчика и подрядчика, где они будут вместе конструировать модель работы IT-системы.

Это ТЗ реально сделать своими силами, но интегратор тоже может помочь, если компания никогда не работала по Agile.

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

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

Заказчик: «Я хочу, чтобы у меня план с фактом вот здесь совпадали, а здесь были такие-то отчеты и т.д.».

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

Как не работает постановка ТЗ

Заказчик: «Я хочу нажать на кнопку и чтоб все было сделано». Интегратор: «Что именно оно должно делать?» Заказчик: «Я не технический специалист».

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

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