Как стать автором
Обновить

Комментарии 14

Пост крутой. Но! Не понимаю, чем же вам чужое ТЗ не угодило — там же требования изложены уже. Возьмите, смотрите только на них — и делов. Почему вы так против?
Спасибо. Дело в том, что ТЗ как правило выглядит уже не как свод требований, а как требования, наложенные на решения в конкретной системе, с учётом её архитектуры, сроков разработки, возможностей и т.д. И от вендора к вендору эти возможности сильно отличаются — начиная от механизма развёртывания и заканчивая инструментами разработки.
Это как книгу по ремонту автомобиля взять от Жигулей и принести владельцу Тойоты — ну это же всё автомобиль: кузов, двигатель, 4 колеса, руль, трансмиссия. Но суть в том, что взаимодействует это всё по-разному, где-то больше тонкостей с электроникой и т.д. Так и в любом софте — ТЗ должно писать именно с учётом программы, которую вы внедряете.
Дело в том, что ТЗ как правило выглядит уже не как свод требований, а как требования, наложенные на решения в конкретной системе, с учётом её архитектуры, сроков разработки, возможностей и т.д.
Если ТЗ писал человек который работал только с 1 системой или-же задача стояла протолкнуть 1 систему то это будет так, в других же случаях описание будет довольно вольным, с чётким описанием требуемых функций, но без явного указания способа их реализации.

Так-же можно договориться изменить ТЗ с учётом возможностей вашей системы, это делается гораздо быстрее и дешевле чем составлять ТЗ с 0.
Если ТЗ больше описывает требования, чем реализацию и ничего «не проталкивает», почему нет? Мы же откроем его и посмотрим с готовностью общаться, а не дадим с размаху от ворот поворот. Но пока такого не встречалось.
У меня такой-же велосипед получается по ТЗ заказчика, прямо таки копия.
Вы анализировали причины, почему так вышло: расплывчатые требования, неграмотное ТЗ или всё сразу?
Тут у нас в 2010 году CRM покупать хотели, ТЗ завалялось.

Любимый вариант многих госструктур, неважно о чём идет речь, о ПО, об оборудовании.
Регулярно выкладывают тендеры на железки снятые с пр-ва 5-6-7-8 лет тому назад.
Внедрять CRM без расписаных бизнес процессов, это заранее обрекать клиента на неудачу!
Тех. задание это выдуманный документ, в большинстве случаев «высосаный из пальца».
Он никогда не будет отражать действительность.
Так же необходимо участие специалиста по «системе менеджмента качества» стандарта 9001.

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

Что касается СМК, то поясните для Хабра, с какого масштаба нужен такой специалист и зачем?
ТЗ не опирающиеся на бизнес-процессы, это возможность распила средств, путем введения ненужных, порой тупиковых идей, которые изначально не будут использоваться, но позволят увеличить бюджет.
А вот специалист по CMK может оптимизировать ваше тех задание, согласуя его с реальными бизнес процессами.
Причем если работа предприятия не оптимизирована по стандарту ISO 9001, то внедрение CRM может не дать ожидаемого эффекта. А порой и усложнить, казалось бы простую работу.
А вот что бы бизнес процессы соответствовали реальному положению вещей тут просто НЕОБХОДИМ специалист аудитор по СМК. Который будет отвечать за эту оптимизацию.
Очень зависит от масштаба компании. Что-то вы не по делу усложняете. Я работал в компании с ISO 9001, так это гигант. И все равно все было проформа, а по сути бардак бардаком. И СМК-шники просыпались только во время очередного подтверждения. Любой адекватный вендор наладит соответствие без лишних помощников. Я понимаю, обидно такое о себе слышать, но такие аудиторы в 90% случаев не нужны абсолютно.
Да я с вами согласен, видел такое же где сделали стандарт, ISO 9001, а бардак остался, по тому как они изначально его же и оптимизировали :) А нужно было сначала сделать оптимальные бизнес процессы и ре инжениринг. Я просто скомкано все изложил.
хорошая статья, спасибо! пожалуй все кейсы описаны — нечего добавить

что есть ТЗ в вашем случае — это формальный документ, который «цементируется» подписями вендора и заказчика? Или это документ, который разработал вендор, а затем с заказчиком обсудили и неформально согласовали?

Спасибо за отзыв!
ТЗ в нашем случае, конечно, оформленный и подписанный сторонами документ, со сроками, ценами, подписями. Короче, полноценное приложение к договору — никаких договорённостей и неформальных согласований. Иначе вся работа может пойти насмарку(
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.