Кое-что из статьи натолкнуло на рассуждение.
"Следующим этапом будет составление технического задания. Оно будет приложением к договору, и должно быть составлено до подписания договора. Техническое задание должны быть очень подробным, чтобы было не к чему в итоге придраться."
По опыту оказалось крайне неверно и привело нас к тому, чтобы сменить бизнес-модель и использовать адаптивный подход.
Грубо говоря, оказалось, что лучше не тратить драгоценное время на написание бесполезной документации типа "очень подробного ТЗ", т.к. даже если в один момент времени заказчик это утвердит, то потом у него у самого будут претензии к результату (и неважно, что он сам подписал это) - это уже станет неактуальным! Не стоит терять время на написание системы (или, скажем, создание сайта) на бумаге - это может занять столько же времени, сколько может уйти на подготовку "опытного образца".
Разумеется, при старой бизнес модели так работать нельзя, ибо получается конфликт двух моментов:
1. Заказчик хочет застолбить сумму, объем работ и сроки и прописать их в договоре (скажем, в виде приложения "ТЗ");
2. Необходимо увеличивать бюджет на то, что заказчик "хочет еще" или снижать на то, что ему перестало (гипотетически) быть нужно уже во время разработки проекта.
Пример:
Допустим, увидев первые наработки, клиент решает, что ему этого достаточно, остального по начальному ТЗ не надо, но надо что-то вообще новое.
Итог:
- К чертям летит договор - все равно требуется доп. соглашение, в котором уточняются измененные виды (или объемы) работ, регламенты, условия и т. д., и т. п.
- Сложности с тем, что нужно как-то аргументировать клиенту необходимость менять бюджет (при изменении в высшую сторону). Вот этот момент большинство почему-то не берет в расчет, считая, что "на месте разберемся". В итоге - многие срабатывают себе в минус и долго ругаются на клиента, который часто в общем-то и не обязан досконально все понимать.
Лично нам помогло грамотное обдумывание ооочень большого количества возможных моментов и изменение бизнес-модели от ориентированной на "конечный продукт" к ориентированной на "постоянное обслуживание".
Чтобы было понятно о чем речь - работа представлена не в виде "компания создает сайт".
Все исходит из другого. Для чего клиенту сайт? Для презентации своей продукции? Так вот, в данном случае "компания решает задачу по поддержке клиента в презентации своей продукции", применяя для этого любые доступные компании-исполнителю методы (которые могут меняться по мере проекта, ровно как и пожелания клиента).
Попробуйте изначально подходить к объяснениям клиенту именно с этой стороны, сразу сделав любые, даже самые значительные изменения "штатной ситуацией", к которой готовы все, включая клиента!
И не тратьте время на создание всесторонне суперпуперпродуманных договоров - лучше обдумайте грамотный подход к созданию соглашений об уровне сервиса (SLA) для своей области деятельности.
P.S. Вышесказанное не претендует на абсолютную объективность, так как нельзя утверждать, что нами были рассмотрены все ситуации, и возможно, кому-то эта модель не подойдет. Однако, я лично (пусть даже субъективно) считаю, что для студий, которые умеют работать, но не имеют такого актива, как "бренд и имя на рынке" - это будет идеальным решением и выживать будут те, которые наиболее "адаптивные", "гибкие".
Кстати, такая бизнес-модель отлично соотносится с Agile-подходами к разработке ПО и является, по сути, реализацией метода "Getting Real".
"Следующим этапом будет составление технического задания. Оно будет приложением к договору, и должно быть составлено до подписания договора. Техническое задание должны быть очень подробным, чтобы было не к чему в итоге придраться."
По опыту оказалось крайне неверно и привело нас к тому, чтобы сменить бизнес-модель и использовать адаптивный подход.
Грубо говоря, оказалось, что лучше не тратить драгоценное время на написание бесполезной документации типа "очень подробного ТЗ", т.к. даже если в один момент времени заказчик это утвердит, то потом у него у самого будут претензии к результату (и неважно, что он сам подписал это) - это уже станет неактуальным! Не стоит терять время на написание системы (или, скажем, создание сайта) на бумаге - это может занять столько же времени, сколько может уйти на подготовку "опытного образца".
Разумеется, при старой бизнес модели так работать нельзя, ибо получается конфликт двух моментов:
1. Заказчик хочет застолбить сумму, объем работ и сроки и прописать их в договоре (скажем, в виде приложения "ТЗ");
2. Необходимо увеличивать бюджет на то, что заказчик "хочет еще" или снижать на то, что ему перестало (гипотетически) быть нужно уже во время разработки проекта.
Пример:
Допустим, увидев первые наработки, клиент решает, что ему этого достаточно, остального по начальному ТЗ не надо, но надо что-то вообще новое.
Итог:
- К чертям летит договор - все равно требуется доп. соглашение, в котором уточняются измененные виды (или объемы) работ, регламенты, условия и т. д., и т. п.
- Сложности с тем, что нужно как-то аргументировать клиенту необходимость менять бюджет (при изменении в высшую сторону). Вот этот момент большинство почему-то не берет в расчет, считая, что "на месте разберемся". В итоге - многие срабатывают себе в минус и долго ругаются на клиента, который часто в общем-то и не обязан досконально все понимать.
Лично нам помогло грамотное обдумывание ооочень большого количества возможных моментов и изменение бизнес-модели от ориентированной на "конечный продукт" к ориентированной на "постоянное обслуживание".
Чтобы было понятно о чем речь - работа представлена не в виде "компания создает сайт".
Все исходит из другого. Для чего клиенту сайт? Для презентации своей продукции? Так вот, в данном случае "компания решает задачу по поддержке клиента в презентации своей продукции", применяя для этого любые доступные компании-исполнителю методы (которые могут меняться по мере проекта, ровно как и пожелания клиента).
Попробуйте изначально подходить к объяснениям клиенту именно с этой стороны, сразу сделав любые, даже самые значительные изменения "штатной ситуацией", к которой готовы все, включая клиента!
И не тратьте время на создание всесторонне суперпуперпродуманных договоров - лучше обдумайте грамотный подход к созданию соглашений об уровне сервиса (SLA) для своей области деятельности.
P.S. Вышесказанное не претендует на абсолютную объективность, так как нельзя утверждать, что нами были рассмотрены все ситуации, и возможно, кому-то эта модель не подойдет. Однако, я лично (пусть даже субъективно) считаю, что для студий, которые умеют работать, но не имеют такого актива, как "бренд и имя на рынке" - это будет идеальным решением и выживать будут те, которые наиболее "адаптивные", "гибкие".
Кстати, такая бизнес-модель отлично соотносится с Agile-подходами к разработке ПО и является, по сути, реализацией метода "Getting Real".
А тут здорово написано и понятно) Буду кидать ссылку заказчикам.