На рынке IT-услуг работает множество небольших независимых команд (организованных групп разработчиков, аналитиков, консультантов и т.п.), которые уже не являются индивидуальными фрилансерами, поскольку выступают перед своими клиентами в качестве единой команды, но еще (или вообще) не являются полноценными фирмами, поскольку в них отсутствуют в законченном виде свойственные организациям «вспомогательные» процессы в следующих областях: работа с кадрами, управленческий и финансовый учет, документооборот и т.п.
Не смотря на это, небольшим командам также приходится в той или иной мере развивать все эти процессы, в т.ч. заниматься их «внутренней автоматизацией». При этом очень важно найти разумный компромисс между функционалом и затратами ресурсов на создание таких «внутренних» IT-решений. Ведь никому не хочется, например, терять часы и деньги, вручную проводя взаиморасчеты между клиентами и членами команды. С другой стороны, никто не хочет тратить свое время и деньги на создание или внедрение «навороченных» систем вместо того, чтобы зарабатывать деньги на коммерческих проектах.
Представляя одну из таких команд, хочу поделиться своим опытом создания небольшой системы для управленческого учета внутри своей команды в формате «IT-кейса».
За время своей работы мне удалось взглянуть на процесс разработки технических заданий на программные продукты с нескольких точек зрения. С точки зрения аналитика – непосредственного исполнителя работ, с точки зрения руководителя проекта со стороны исполнителя, организующего процесс создания ТЗ, с точки зрения руководителя группы разработчиков, реализующих эти самые ТЗ, а также с точки зрения заказчика системы, впоследствии принимающего решение по разработанному ранее ТЗ.
Надо сказать, что у каждой из этих заинтересованных сторон свои требования и свое видение того, каким должно быть «хорошо написанное ТЗ». Например, у заказчика и исполнителя могут быть совершенно противоположные мнения на этот счет. Исполнитель может быть заинтересован в максимально подробном ТЗ для того, чтобы максимально формализовать свои обязательства по функционалу создаваемого решения. При этом заказчик, который точно не определился с параметрами будущей системы или у которого «ветер в голове», может требовать более общих формулировок, описания системы крупными мазками для того, чтобы потом попытаться включить в рамки оговоренного бюджета новые требования. Конечно же, при другом «менталитете» заказчика и исполнителя все может быть с точностью до наоборот. Сейчас мне хотелось бы остановиться именно на разработке ТЗ с точки зрения его заказчика, рассмотрев возможные ситуации, цели и тактики поведения.
