Comments 212
Что такое «работа без ТЗ»?
Это когда заказчик сам не приносит готовое ТЗ? Ну так бывает в 99% случаев. И слава богу. Потому что когда приходят с готовым ТЗ — там такой АД, как правило…
Нормальный workflow:
Приходит заказчик. Расписывает чего хочет. Я составляю ему ТЗ(иногда бесплатно, иногда за деньги). После чего ТЗ утверждается и мы дальше спокойно работаем.
Уверен, что большая часть проголосовавших за «Иногда работаю без ТЗ» — также делает — составляет ТЗ самостоятельно. А автор почему-то решил, что все поголовно делают «не знаю что, но надо сделать».
Это когда заказчик сам не приносит готовое ТЗ? Ну так бывает в 99% случаев. И слава богу. Потому что когда приходят с готовым ТЗ — там такой АД, как правило…
Нормальный workflow:
Приходит заказчик. Расписывает чего хочет. Я составляю ему ТЗ(иногда бесплатно, иногда за деньги). После чего ТЗ утверждается и мы дальше спокойно работаем.
Уверен, что большая часть проголосовавших за «Иногда работаю без ТЗ» — также делает — составляет ТЗ самостоятельно. А автор почему-то решил, что все поголовно делают «не знаю что, но надо сделать».
«Я составляю ему ТЗ(иногда бесплатно, иногда за деньги). После чего ТЗ утверждается и мы дальше спокойно работаем.»
Вы большой молодец, но так далеко не у всех происходит, к сожалению.
Вы большой молодец, но так далеко не у всех происходит, к сожалению.
ИМХО пару раз поработаешь без точного определения что нужно делать — и сам начнешь ТЗ составлять.
Потому что переделки и хотелки заказчика нужно ограничивать, иначе они вылазят далеко за пределы срока и бюджета.
Так что я уверен, что большинство так делает. Просто первоначальный опрос не раскрывает это.
Потому что переделки и хотелки заказчика нужно ограничивать, иначе они вылазят далеко за пределы срока и бюджета.
Так что я уверен, что большинство так делает. Просто первоначальный опрос не раскрывает это.
Думаю вы просто сами умеете делать правильно и вам кажется, что иначе нельзя -)
Далеко не все делают правильные выводы из сложившейся ситуации, и это не только разработки ПО касается.
По предыдущему материалу есть не только голосования, но и комменты. И в этих комментах есть даже защитники БезТЗ.
Далеко не все делают правильные выводы из сложившейся ситуации, и это не только разработки ПО касается.
По предыдущему материалу есть не только голосования, но и комменты. И в этих комментах есть даже защитники БезТЗ.
Есть несколько знакомых, которые владельцы студий по разработке сайтов, либо фрилансеры на проекты (не на мелкие доработки, а сайты целиком, например). Все начинали без ТЗ, но после 1-2 проколов студии сами пишут ТЗ и берут за это деньги (включают в стоимость работ), а фрилансеры — как договорятся, иногда берут деньги заранее, иногда в стоимость работы просто приплюсовывают.
Зависит просто от размера проекта в первую очередь
Мы аналогично работаем (я, если что, заказчик):
1. Набрасываю в обычном альбоме маркерами как я проект вижу.
2. Отмечаю в том же альбоме какие-то моменты. на которые надо обратить внимание.
3. Фотографирую этот альбом и отправляю руководителю проекта, чтобы он подготовился к моему визиту в общих чертах и договариваемся о встрече
4. Вместе пишем ТЗ (от 15 минут до 2-х часов), дабы убедиться, что мы друг друга понимаем
5. Мне присылают расчет на основе стоимости человеко-часа и, если всё норм, оплачиваю
6. Работаем. Результат принимается примерно как у всех.
В данном же случае мы, по моему мнению, без ТЗ работаем. Но работаем. И отлично, я считаю, работаем.
1. Набрасываю в обычном альбоме маркерами как я проект вижу.
2. Отмечаю в том же альбоме какие-то моменты. на которые надо обратить внимание.
3. Фотографирую этот альбом и отправляю руководителю проекта, чтобы он подготовился к моему визиту в общих чертах и договариваемся о встрече
4. Вместе пишем ТЗ (от 15 минут до 2-х часов), дабы убедиться, что мы друг друга понимаем
5. Мне присылают расчет на основе стоимости человеко-часа и, если всё норм, оплачиваю
6. Работаем. Результат принимается примерно как у всех.
В данном же случае мы, по моему мнению, без ТЗ работаем. Но работаем. И отлично, я считаю, работаем.
Какой же это без ТЗ? O_o
4. Вместе пишем ТЗ (от 15 минут до 2-х часов), дабы убедиться, что мы друг друга понимаем
Ну фундаментально я ж без ТЗ прихожу к исполнителю. И с исполнителем мы ТЗ составляем. Причем, не заморачиваемся на формальности и пишем ТЗ буквально «на пальцах». Но мы с исполнителем друг друга понимаем и проблем пока не было.
Если это требует, кстати, дополнительной оплаты исполнителю — окей. Это ж как проект, ремонта, допустим, квартиры, или тюнинга машины: без плана работ нельзя. Тем более как без этого самого плана можно вообще предварительно посчитать стоимость работ? Я не знаю как. Но план работ и ТЗ — это, имхо, не совсем одно и то же.
Если это требует, кстати, дополнительной оплаты исполнителю — окей. Это ж как проект, ремонта, допустим, квартиры, или тюнинга машины: без плана работ нельзя. Тем более как без этого самого плана можно вообще предварительно посчитать стоимость работ? Я не знаю как. Но план работ и ТЗ — это, имхо, не совсем одно и то же.
Когда работать начали Без ТЗ — так нехорошо
А когда потратили два часа на ТЗ и начали работать — так идеально
Вы и ваши разрабы все делаете правильно
А когда потратили два часа на ТЗ и начали работать — так идеально
Вы и ваши разрабы все делаете правильно
> Вы и ваши разрабы все делаете правильно
Да, но судя по всему, вы сделали неверные суждения по прошлому голосованию.
А значит, вам нужно обновить статью: либо убрать критику таких «разработчиков»,
либо сделать апдейт, и указать, что «Как показал опрос в комментариях, понимание автора о ТЗ сильно отличается от понимания других разработчиков и заказчиков о ТЗ».
Да, но судя по всему, вы сделали неверные суждения по прошлому голосованию.
А значит, вам нужно обновить статью: либо убрать критику таких «разработчиков»,
либо сделать апдейт, и указать, что «Как показал опрос в комментариях, понимание автора о ТЗ сильно отличается от понимания других разработчиков и заказчиков о ТЗ».
Не разводите демагогию!
Без ТЗ это когда устно заказчик что-то рассказывает и показывает на пальцах. Через неделю всё забывает и надо переделывать потому что новый рассказ или «а я думал вы меня поняли» о совсем другом…
Так же без ТЗ это когда формально ТЗ есть но заказчик на него не смотрит и всё еще продолжает устно вносить противоречащие самому себе правки в ходе разработки заставляя тем самым многократно верстать одно и тоже или переписывать один и тот же код под другую логику.
То что вы написали это работа с ТЗ, только ТЗ вы делаете сами и утверждаете с заказчиком.
А наличие ТЗ в первую очередь заставляет делать работу один раз, а не переделывать еще не сделанное много раз.
Без ТЗ это когда устно заказчик что-то рассказывает и показывает на пальцах. Через неделю всё забывает и надо переделывать потому что новый рассказ или «а я думал вы меня поняли» о совсем другом…
Так же без ТЗ это когда формально ТЗ есть но заказчик на него не смотрит и всё еще продолжает устно вносить противоречащие самому себе правки в ходе разработки заставляя тем самым многократно верстать одно и тоже или переписывать один и тот же код под другую логику.
То что вы написали это работа с ТЗ, только ТЗ вы делаете сами и утверждаете с заказчиком.
А наличие ТЗ в первую очередь заставляет делать работу один раз, а не переделывать еще не сделанное много раз.
Вы похоже не внимательно читали(интересно ТЗ вы также внимательно читаете?).
Я и говорю — что это фактически работа с ТЗ. Но, например, исполнители отвечали что работают без ТЗ, хотя фактически сами его делали, и по факту ответ не соответствовал действительности.
Так что удосужтесь прочитать то, что комментируете.
Я и говорю — что это фактически работа с ТЗ. Но, например, исполнители отвечали что работают без ТЗ, хотя фактически сами его делали, и по факту ответ не соответствовал действительности.
Так что удосужтесь прочитать то, что комментируете.
И вот тут выходит косяк на стадии сдачи проекта. Выясняется, что когда заказчик что-то с вами описывал в ТЗ не учел еще целый ряд своих хотелок, и если вы начнете с ним аргументированно спорить и приводить в качестве довода, составленный вами же ТЗ, то боюсь заказчик будет думать, что его обманули. Конечно есть много способов урегулировать такой конфликт («и рыбку съесть и… в лодку сесть» ©), но осадочек может остаться.
Заказчик, заказчику рознь, но часто бывает так, что расписываешь ТЗ с одним человеком, а принимает другой или вообще целый ворох людей во главе с руководителем заказчика. Даже если ТЗ прошло согласование с руководителем заказчика, и стоит подпись руководителя, все равно можешь быть виноват!
Заказчик, заказчику рознь, но часто бывает так, что расписываешь ТЗ с одним человеком, а принимает другой или вообще целый ворох людей во главе с руководителем заказчика. Даже если ТЗ прошло согласование с руководителем заказчика, и стоит подпись руководителя, все равно можешь быть виноват!
У меня есть решение!
Нужно ТЗ регулярно проговаривать, чтобы оно не забывалось.
Не 100% защита, конечно, но помогает.
Нужно ТЗ регулярно проговаривать, чтобы оно не забывалось.
Не 100% защита, конечно, но помогает.
Ну это рабочий момент.
Переговоры никто не отменял.
ТЗ — это способ объединить видение.
Доделки и хотелки — отдельная тема и обсуждается отдельно.
В зависимости от ситуации, иногда я хотелки/доделки делаю бесплатно, иногда за отдельную плату.
Всё сильно от ситуации зависит. Мне кажется особой связи с ТЗ тут нет.
Переговоры никто не отменял.
ТЗ — это способ объединить видение.
Доделки и хотелки — отдельная тема и обсуждается отдельно.
В зависимости от ситуации, иногда я хотелки/доделки делаю бесплатно, иногда за отдельную плату.
Всё сильно от ситуации зависит. Мне кажется особой связи с ТЗ тут нет.
Нет самого интересного варианта. «Работаю на доверии». А уж как завоевать обоюдное доверие — это отдельный вопрос.
Доверие никак не связано с ТЗ.
У меня по большинству заказчиков «открытый договор». Акт о проделанной работе я сдавал последний раз лет 5 назад. Но при этом со всеми заказчиками есть ТЗ.
У меня по большинству заказчиков «открытый договор». Акт о проделанной работе я сдавал последний раз лет 5 назад. Но при этом со всеми заказчиками есть ТЗ.
На мой взгляд, проектирование не отделимо от программирования. Обе фазы чередуются в процессе разработки. Поэтому я и не выделяю этап составления ТЗ.
Мне приходилось иметь дело с оформлением по ГОСТу, польза от потраченного времени была исчезающей. Вот без этого формального подготовительного процесса я предпочитаю обходиться.
Мне приходилось иметь дело с оформлением по ГОСТу, польза от потраченного времени была исчезающей. Вот без этого формального подготовительного процесса я предпочитаю обходиться.
А заказчик вам платит за ТЗ? Или как вы договариваетесь, если он, в итоге, не закажет, например. Вот, для меня это самая большая проблема, например: куча работы по исследованиям проблемы и пресейлзу, а потом заказчик пропадает.
Для очень жирных проектов — это абсолютно нормально.
Да, можно пресейлз и месяц делать. Да, кто-то сливается.
А те, кто не сливаются — платят 100500 * 100500 * 100500 денег, что все компенсирует.
В мелких проектах пресейлз и ТЗ на 1 час? Это вообще не затраты.
Проблемы начинаются когда большой пресейлз и бесплатное ТЗ делается на не очень денежных проектов.
Ну дык ты сам себе злой буратино — риски и прибыль оцениваются. Можно даже чисто арифметически расчитать когда овичнка выделки стоит. Уже не говоря про то, что опытный разраб обладает чувством в шестой точке.
Да, можно пресейлз и месяц делать. Да, кто-то сливается.
А те, кто не сливаются — платят 100500 * 100500 * 100500 денег, что все компенсирует.
В мелких проектах пресейлз и ТЗ на 1 час? Это вообще не затраты.
Проблемы начинаются когда большой пресейлз и бесплатное ТЗ делается на не очень денежных проектов.
Ну дык ты сам себе злой буратино — риски и прибыль оцениваются. Можно даже чисто арифметически расчитать когда овичнка выделки стоит. Уже не говоря про то, что опытный разраб обладает чувством в шестой точке.
А что вы называете буквами «ТЗ»? То, на что есть ГОСТ? А вы такое сами составить пробовали?
Обычно заказчик примерно знает, чего он хочет (очень примерно), на основании детального допроса делается общий план сверху и детальное представление о том, что делать, на итерацию (1-2 недели). Все целиком сразу и подробно расписывать смысла нет, потому что он еще передумает сто раз, и это нормально. Как расписывается итерация — зависит от достигнутого уровня взаимопонимания: сначала, пока друг в друге не уверены, можно и приложение к договору расписать, а со временем и увеличением взаимопонимания и доверия уже хватает логов чата и зарисовок на салфетке. Обычно удобнее всего мокапы с комментариями.
Обычно заказчик примерно знает, чего он хочет (очень примерно), на основании детального допроса делается общий план сверху и детальное представление о том, что делать, на итерацию (1-2 недели). Все целиком сразу и подробно расписывать смысла нет, потому что он еще передумает сто раз, и это нормально. Как расписывается итерация — зависит от достигнутого уровня взаимопонимания: сначала, пока друг в друге не уверены, можно и приложение к договору расписать, а со временем и увеличением взаимопонимания и доверия уже хватает логов чата и зарисовок на салфетке. Обычно удобнее всего мокапы с комментариями.
ТЗ — это то, что позволяет однозначно ответить на вопрос: соответствует результат ожиданиям или нет.
А уж его форма и содержание — дело десятое.
А уж его форма и содержание — дело десятое.
А тут дело тогда не в ТЗ, а в том, чтобы четко понять задачу и убедиться, что понимание соответствует тому, что в голове у заказчика. А уж как это фиксировать — зависит от множества факторов.
ТЗ — это и есть фиксация задачи.
Или в чем еще вы видите его суть?
Или в чем еще вы видите его суть?
А по-всякому бывает. Часто суть в том, чтобы прикрыть свою задницу.
Я неоднократно видел ТЗ, в которых налита куча воды, но при этом никто даже не попытался понять, что на самом деле заказчику нужно, в чем его проблемы. Заказчик смотрит, ну вроде «с его слов записано верно», а потом через месяца три смотрит на результат (формально целиком соответствующий этому ТЗ) и плачет.
Я неоднократно видел ТЗ, в которых налита куча воды, но при этом никто даже не попытался понять, что на самом деле заказчику нужно, в чем его проблемы. Заказчик смотрит, ну вроде «с его слов записано верно», а потом через месяца три смотрит на результат (формально целиком соответствующий этому ТЗ) и плачет.
Вы видели ТЗ, которое действительно позволяет однозначно ответить на вопрос: соответствует результат ожиданиям или нет для проектов, продолжительностью более 3 месяцев?
Такие проекты делятся на этапы. ТЗ к каждому этапу отдельно составляется.
Видел.
Неоднократно.
Неоднократно.
А я считаю вы правы по поводу однозначности.
Тут всегда есть какой-то предел разумного, как в той статье про то как разных разрабов попросили файл скопировать в качестве тестовой задачи. И появилось столько радикально разных реализаций!
Причем по ходу прочтения таких историй становится понятно, что исчерпывающее ТЗ на копирование файла, даже если оно будет огромным просто невозможно.
В целом ТЗ это скорее ориентир, а не однозначный ответ на вопрос, к сожалению.
Тут всегда есть какой-то предел разумного, как в той статье про то как разных разрабов попросили файл скопировать в качестве тестовой задачи. И появилось столько радикально разных реализаций!
Причем по ходу прочтения таких историй становится понятно, что исчерпывающее ТЗ на копирование файла, даже если оно будет огромным просто невозможно.
В целом ТЗ это скорее ориентир, а не однозначный ответ на вопрос, к сожалению.
Есть ПЗ (постановка задачи) и есть ТЗ. Как пример
ПЗ — ускорить работу программы минимум на 30 процентов.
ТЗ… теоретически там должно быть написано на сколько мы ускоряем каждый из этапов разработки и за счет чего (расход памяти, улучшенные алгоритмы...),… Практически, пока весь код не прочел — это непонятно.
Поэтому на таких задачах — работаем без ТЗ,
ПЗ — ускорить работу программы минимум на 30 процентов.
ТЗ… теоретически там должно быть написано на сколько мы ускоряем каждый из этапов разработки и за счет чего (расход памяти, улучшенные алгоритмы...),… Практически, пока весь код не прочел — это непонятно.
Поэтому на таких задачах — работаем без ТЗ,
А вы видели это ГОСТ-34 из замшелых 80-х годов?
В чем проблема работать без ТЗ по Agile при T&M-схеме оплаты?
В выгорании
Увы, но чудес не бывает даже в Agile. :)
У вас есть Story клиента, как минимум. У вас есть планирование, как минимум.
На этих двух этапах вы и делаете «магию» ТЗ — что надо сделать и как. что уже подразумевает явную связку «Ожидания Клиента» — «Сделаем Так».
Если клиенту процесс разработки не подходит, то меняется процесс или клиент.
У вас есть Story клиента, как минимум. У вас есть планирование, как минимум.
На этих двух этапах вы и делаете «магию» ТЗ — что надо сделать и как. что уже подразумевает явную связку «Ожидания Клиента» — «Сделаем Так».
Если клиенту процесс разработки не подходит, то меняется процесс или клиент.
По мне так идеальная схема для всех.
Заказчик не хочет писать ТЗ — не пишет ТЗ.
Разраб хочет денег — любые переделки/доделки оплачиваются.
а где «программа нужна вчера, а писать тз — неделя»?
Думали в этом направлении. По опыту все-таки ТЗ тут экономит время и все ускоряет. Правда-правда.
Хотя аргумент такой заказчики используют, вы правы.
Хотя аргумент такой заказчики используют, вы правы.
Простенькой ТЗ пишется за несколько часов. И всё равно нужно структурировать понимание. Проще всего совмещать — пишем ТХ параллельно с этим формируем видение проекта.
«Воспоминания» заказчкика о том, как должен выглядеть и работать результат порой могут меняться по несколько раз на дню.
Без фиксации договоренностей, вы выйдете в бесконечный «agile». И или растянете сроки, или бюджет, или получите недовольного результатом заказчика.
А фиксация в итоге приведет вас к ТЗ. И это справедливо даже для «микро-проектов», которые вы можете сделать за 1 день, пусть даже в виде ТЗ будет выступать некое письмо заказчика и ваш ответ с перечислением фич к реализации.
Без фиксации договоренностей, вы выйдете в бесконечный «agile». И или растянете сроки, или бюджет, или получите недовольного результатом заказчика.
А фиксация в итоге приведет вас к ТЗ. И это справедливо даже для «микро-проектов», которые вы можете сделать за 1 день, пусть даже в виде ТЗ будет выступать некое письмо заказчика и ваш ответ с перечислением фич к реализации.
Agile оплачивается все это время…
;)
;)
«Любой каприз за ваши деньги», к сожалению имеет и обратную сторону., как я уже писал выше «растянете сроки, или бюджет, или получите недовольного результатом заказчика». В результате страдает ваша репутация.
Гораздо правильнее убедить заказчика и сделать то, что ему действительно нужно. Конечно на это часто требуется потратить уйму сил и ресурсов, но ваша карма и репутация несомненно будет в плюсе. А у заказчика, которого вы убедили сделать по вашему и сделали все хорошо будет для вас большой кредит доверия как в рамках разработки, так и в рамках принятия решений.
Более того, если вы в результате не договорились и разошлись. А заказчик нашел более сговорчивого по сценарию «Любой каприз за ваши деньги», после попадания на сроки/деньги/результат, ваши мудрые слова вспомнят и опять же ваш рейтинг повысится :)
Гораздо правильнее убедить заказчика и сделать то, что ему действительно нужно. Конечно на это часто требуется потратить уйму сил и ресурсов, но ваша карма и репутация несомненно будет в плюсе. А у заказчика, которого вы убедили сделать по вашему и сделали все хорошо будет для вас большой кредит доверия как в рамках разработки, так и в рамках принятия решений.
Более того, если вы в результате не договорились и разошлись. А заказчик нашел более сговорчивого по сценарию «Любой каприз за ваши деньги», после попадания на сроки/деньги/результат, ваши мудрые слова вспомнят и опять же ваш рейтинг повысится :)
Считаю, что ТЗ нужно составлять не из соображений «иди мне и распиши как надо», а из соображений «чувак, над твоим проектом придется работать, долго работать, ОЧЕНЬ ДОЛГО работать, ты хотя бы составь ТЗ, чтобы понять насколько это сложно, а потом будем обсуждать оплату».
Обычно «маленький сайтик с регистрацией, начислением баллов, магазином сувениров и регистрацией» предполагается как штука, которую подобно кролику достали из шляпы (актуально: «возьмите готовое решение, вон их сколько»), попытка объяснить, что это все придется делать, причем заново, заканчивается в лучшем случае обвинением в непрофессионализме, в худшем — «я сюда не поговорить пришел, а найти профессионала, мои деньги стоят для меня очень дорого, не хочешь ты, найдем другого лоха».
А вот когда он сам составит ТЗ — ему наверное больно узнавать, что мне его ТЗ ни в болт не впилось, но это необходимая точка сортировки клиентов — если он «смог» составить ТЗ, значит он понимает, за что и почему он платит.
Обычно «маленький сайтик с регистрацией, начислением баллов, магазином сувениров и регистрацией» предполагается как штука, которую подобно кролику достали из шляпы (актуально: «возьмите готовое решение, вон их сколько»), попытка объяснить, что это все придется делать, причем заново, заканчивается в лучшем случае обвинением в непрофессионализме, в худшем — «я сюда не поговорить пришел, а найти профессионала, мои деньги стоят для меня очень дорого, не хочешь ты, найдем другого лоха».
А вот когда он сам составит ТЗ — ему наверное больно узнавать, что мне его ТЗ ни в болт не впилось, но это необходимая точка сортировки клиентов — если он «смог» составить ТЗ, значит он понимает, за что и почему он платит.
Хорошо наверное жить в Ривенделле, где хороших заказчиков хватает на всех, надо только чуть-чуть поискать.
В Мордоре же, где 95% исполнителей работают без ТЗ, а 4% с бюджетами минимум от 10 миллионов, быть в оставшемся 1% крайне непросто.
Если бюджет большой, то ваша компания из 10 человек «слишком мелкая», а если не большой, то клиент скажет «а какое ТЗ, уйду ка я прямо щас к конкурентам».
В Мордоре же, где 95% исполнителей работают без ТЗ, а 4% с бюджетами минимум от 10 миллионов, быть в оставшемся 1% крайне непросто.
Если бюджет большой, то ваша компания из 10 человек «слишком мелкая», а если не большой, то клиент скажет «а какое ТЗ, уйду ка я прямо щас к конкурентам».
Мне как раз говорят: как хорошо, что все с ТЗ. Конкуренты обещали: «все сделаем в лучшем виде», а вы вопросы задаете, какие молодцы.
Еще ни разу в жизни мне не попадался бы клиент, который бы отказался работать по составленному мной для его проекта ТЗ.
Зато у меня встречался тот, который пока я составляю ТЗ заказывает у того, кто «больше сотрудников в штате имеет», или просто «у друга»
Сложность не составить ТЗ, а упросить его начать работать с тобой, пока у тебя еще нет ТЗ
Сложность не составить ТЗ, а упросить его начать работать с тобой, пока у тебя еще нет ТЗ
Заказчики иногда уходят. Это нормально.
А надо чтобы он участвовал в создании ТЗ и включился в работу в месте с вами.
И лучше конечно, чтобы оплатил ТЗ, это тоже привязывает и заставляет более серьезно подойти к утверждению.
И лучше конечно, чтобы оплатил ТЗ, это тоже привязывает и заставляет более серьезно подойти к утверждению.
Я на старте оговариваю стоимость ис роки составления ТЗ. Если клиент новый — предоплата ТЗ 100%. Если проект стартует, то стоимость ТЗ списывается со стоимости заказа.
Мне попадался: «Мы не можем ничего согласовать, так как это отрежет нам дорогу к изменениям».
Или: «Мы не можем согласовать, т.к. не знаем как должно быть, но начинать надо сейчас»
Или: «Мы не можем согласовать, т.к. не знаем как должно быть, но начинать надо сейчас»
А можно поподробнее?
Эти байки были бы весьма интересны.
Эти байки были бы весьма интересны.
Это еще ничего.
Мне попадался совсем забавный кадр. Прислал email с описанием, чего он хочет (это был первый контакт, до этого не общались). На следующий день, когда я с ним связался, чтобы обсудить возможное сотрудничество, он спросил — «как, а что, вы еще не начали делать? Почему?»
Мне попадался совсем забавный кадр. Прислал email с описанием, чего он хочет (это был первый контакт, до этого не общались). На следующий день, когда я с ним связался, чтобы обсудить возможное сотрудничество, он спросил — «как, а что, вы еще не начали делать? Почему?»
Мне попадался: «Мы не можем ничего согласовать, так как это отрежет нам дорогу к изменениям».
Или: «Мы не можем согласовать, т.к. не знаем как должно быть, но начинать надо сейчас»
Слова Agile, Scrum, Kanban и т.д. летят из каждого утюга уже лет 7… Как они смогли пролететь мимо Вас?
Это всё именно для таких заказчиков и придумано. Можно конечно условно сказать, что у вас есть некое подобие ТЗ на ближайшие 2 недели, но по факту это явно пункт "работаю без ТЗ", т.к. ТЗ на весь проект не пишется.
1. По Agile и Scrum работаю
2. ТЗ на весь проект избегаю писать, пишу на первый маленький этап
Как по Agile и Scrum прогнозировать бюджеты и сроки мне так и не стало понятно.
Как делаете вы, при условии, что клиент не согласен выкупить время например 5-ти разработчиков на непредсказуемое количество дней, пока проект не будет сделан?
2. ТЗ на весь проект избегаю писать, пишу на первый маленький этап
Как по Agile и Scrum прогнозировать бюджеты и сроки мне так и не стало понятно.
Как делаете вы, при условии, что клиент не согласен выкупить время например 5-ти разработчиков на непредсказуемое количество дней, пока проект не будет сделан?
В моём понимании ТЗ — это официальный документ, подписанный с двух сторон, с описанием в том числе и мелких деталей. План итерации — это скорее неподписанный каркас для "мини-ТЗ".
Как делаете вы, при условии, что клиент не согласен выкупить время например 5-ти разработчиков на непредсказуемое количество дней, пока проект не будет сделан?
Не работаем с ним :-)
Тут в принципе выбор: либо вы работаете по водопаду (и сами себе буратино), либо штампуете типовые проектики, либо у вас неизвестный бюджет и сроки. Можно давать клиенту пробный период 2-3 месяца, если он раньше не работал по такой схеме, прежде чем какие-то долгосрочные договора заключать.
Важно, что при Agile вы должны даже за этот короткий срок выдать что-то работающее. Имхо, абсолютная противоположность ТЗ-подходу.
Эмм ну у меня мини-этапы подписанные делятся от недели до месяца (иногда до двух). И клиент получает что-то работающее по опыту через неделю-две.
Стараемся каждую неделю выпускать демонстрации.
А что вы делаете, если у вас 5 разрабов на Agile пилят проект, а потом у клиента наступает внутреннее согласование с глобалами месяца на полтора два, ато и на 3-4.
Или же просто пауза на 15 дней пока данные необходимые на стороне клиента подготовят, или инфраструктуру (которую вы не можете у себя продублировать), или ждем ответа из глобального IT-суппорта по недокументированным глюкам в API.
1. Что делают в это время 5 разрабов?
2. Если они простаивают, кто им платит за простой?
3. С потоком внезапных, срочных, и важных тикетов на суппорт (т.е. очевидно, что 100% ваша вина, а не клиента) по прошлым проектам, которые отвлекают команду от текущего спринта что делаете?
Стараемся каждую неделю выпускать демонстрации.
А что вы делаете, если у вас 5 разрабов на Agile пилят проект, а потом у клиента наступает внутреннее согласование с глобалами месяца на полтора два, ато и на 3-4.
Или же просто пауза на 15 дней пока данные необходимые на стороне клиента подготовят, или инфраструктуру (которую вы не можете у себя продублировать), или ждем ответа из глобального IT-суппорта по недокументированным глюкам в API.
1. Что делают в это время 5 разрабов?
2. Если они простаивают, кто им платит за простой?
3. С потоком внезапных, срочных, и важных тикетов на суппорт (т.е. очевидно, что 100% ваша вина, а не клиента) по прошлым проектам, которые отвлекают команду от текущего спринта что делаете?
Эмм ну у меня мини-этапы подписанные делятся от недели до месяца (иногда до двух).
И Вы их прям как ТЗ детально расписываете? Имхо, какая-то излишняя бюрократия, зря время отнимающая. Но если клиенту нравится такой подход, то ok.
И клиент получает что-то работающее по опыту через неделю-две.
Да, в идеале после каждой итерации. Но как Вы умудряетесь это ассоциировать с разработкой по ТЗ, я честно говоря не улавливаю.
При затыках со стороны клиента есть несколько вариантов: временно перебросить на другой проект или на внутренний проект, либо по согласованию с клиентом занять непродуктовыми задачами, типа оптимизаций и горизонтального масштабирования.
С потоком внезапных, срочных, и важных тикетов на суппорт по прошлым проектам
Т.е. есть проект, по которому разработка уже не ведётся, и вдруг оттуда прилетает поток внезапных, срочных, и важных тикетов? это как вообще? У нас такого не было.
А для мелких доработок по старым проектам есть выделенный человек, он же сортирует тикеты в техподдержку по текущим.
У меня блочное ТЗ.
-Каждый блок — пользовательский сценарий.
-К каждому блоку есть список экранов.
Клиент понимает сценарий, разработчики понимают сценарий.
Дальше эти блоки встают в таскменеджер и все едет.
Иногда клиент думает несколько месяцев и появляется до 7 версий этого короткого ТЗ.
Поток тикетов генерируется просто. Систему сдали, в эксплуатацию ввели, акты подписали, деньги получили. И тут через полгода пользователи такие решили ее использовать и нашли невыловленные баги. Ну такое с кем угодно может быть -)
Ну а вот выделенный человек он разработчик и сидит вкуривает в старые проекты? Или он менеджер, который коллекционирует баги и отвлекает команду от текущих проектов?
-Каждый блок — пользовательский сценарий.
-К каждому блоку есть список экранов.
Клиент понимает сценарий, разработчики понимают сценарий.
Дальше эти блоки встают в таскменеджер и все едет.
Иногда клиент думает несколько месяцев и появляется до 7 версий этого короткого ТЗ.
Поток тикетов генерируется просто. Систему сдали, в эксплуатацию ввели, акты подписали, деньги получили. И тут через полгода пользователи такие решили ее использовать и нашли невыловленные баги. Ну такое с кем угодно может быть -)
Ну а вот выделенный человек он разработчик и сидит вкуривает в старые проекты? Или он менеджер, который коллекционирует баги и отвлекает команду от текущих проектов?
Клиент понимает сценарий, разработчики понимают сценарий.
Дальше эти блоки встают в таскменеджер и все едет.
Имхо, это не по ТЗ, это BDD называется :-)
Систему сдали, в эксплуатацию ввели, акты подписали, деньги получили. И тут через полгода пользователи такие решили ее использовать и нашли невыловленные баги.
У вас просто какая-то особая специфика.
Ну а вот выделенный человек он разработчик и сидит вкуривает в старые проекты?
Программист.
а если не большой, то клиент скажет «а какое ТЗ, уйду ка я прямо щас к конкурентам».
А вообще опытные заказчики отнюдь не стремяться уйти от тебя,
услышав о ТЗ.
Напротив.
Скорее стремятся уйти те, кто только начинающие,
а они еще не знают сколько стоит разработка ПО («сколько-сколько стоит эта ерунда»)
или, напротив, для которых стоимость значения не имеет,
а имеет значение собственный комфорт
(заняты, доверяют вкусу разработчика).
Я просто закладываю риски работы без ТЗ, умножая стоимость работ на 2 на 3 — в зависимости от того как хорошо знаком с заказчиком.
Так просто в Мордоре опытный заказчик — зверь редкий, в основном залётный. Если этого страшного слова не пугается, то первый, к кому он приходит, вцепляется мёртвой хваткой, лишь бы к «колегам по цеху» случайно не забрёл.
А так по схеме " умножая стоимость" все и работают. Зато навык прорицания прокачивается до такой степени, что уровень хаоса в предстоящем проекте угадывается по первым телефонным гудкам :)
А так по схеме " умножая стоимость" все и работают. Зато навык прорицания прокачивается до такой степени, что уровень хаоса в предстоящем проекте угадывается по первым телефонным гудкам :)
Версия 12: Работаю без ТЗ, потому-что сам его составляю вместе с заказчиком.
При этом понимаю заказчика с полуслова. Плюс советую заказчику от чего отказаться, а это лучше сделать вот так.
И так продолжается уже много лет, все стороны очень довольны. В прошлом голосовании голосовал как «работаю без ТЗ», потому-что действительно работаю не для выполнения ТЗ, а для решения проблемы заказчика. И да, у нас доверительные отношения, поэтому сразу несколько пунктов сливаются в один.
При этом понимаю заказчика с полуслова. Плюс советую заказчику от чего отказаться, а это лучше сделать вот так.
И так продолжается уже много лет, все стороны очень довольны. В прошлом голосовании голосовал как «работаю без ТЗ», потому-что действительно работаю не для выполнения ТЗ, а для решения проблемы заказчика. И да, у нас доверительные отношения, поэтому сразу несколько пунктов сливаются в один.
Я разработчик десктопного и мобильного софта в продуктовой компании из меньше чем 10 человек. ТЗ в глаза не видел :) Есть успешно работающий продукт, которые продаётся; есть product owner с видением дальнейшего развития проекта, есть пользователи, которые присылают пожелания, и есть баг-трекер. Больше, вроде, ничего не требуется.
О! Как хорошо, что вы появились.
Вы с нуля прямо взялись, или просто патчи пишите?
В каком виде вам задачи формулируются? Есть ли таск-трэкер?
Вы с нуля прямо взялись, или просто патчи пишите?
В каком виде вам задачи формулируются? Есть ли таск-трэкер?
Над кокретно моим проектом работал один человек, 5 лет назад взяли меня в помощь, мы вдвоём с нуля написали важную функциональность. С тех пор лично я примерно половину проекта переписал — если не с нуля, то как минимум причесал код. Пару лет назад начал помогать и на другом проекте, «флагманском» продукте компании, который, кроме меня, 1.5 человека делают.
Задачи формулируются чаще устно, иногда в виде тасков/багрепортов в Jira. Но в целом багтрекером пользуемся редко. Я туда записываю только ошибки, о которых сразу понимаю, что исправим нескоро. Если примерно понимаю, как исправить — сразу беру и делаю.
Задачи формулируются чаще устно, иногда в виде тасков/багрепортов в Jira. Но в целом багтрекером пользуемся редко. Я туда записываю только ошибки, о которых сразу понимаю, что исправим нескоро. Если примерно понимаю, как исправить — сразу беру и делаю.
Ну все-таки жира есть.
Может у вас заказчик просто не сильно требовательный и на многое закрывает глаза?
Мне каждый день вываливается такой лист, что его невозможно просто в голове удержать.
Не понимаю как вы устно вообще можете работать!
Может у вас заказчик просто не сильно требовательный и на многое закрывает глаза?
Мне каждый день вываливается такой лист, что его невозможно просто в голове удержать.
Не понимаю как вы устно вообще можете работать!
Мне каждый день вываливается такой лист, что его невозможно просто в голове удержать
Если вы именно бизнес-аналитик, как написано в вашем профиле — то это и есть основная часть вашей работы.
Для разработчика же работа с требованиями важная, но не самая большая часть работы.
Так что все логично.
Если жира отвалится, заметим месяца через 3, не раньше. И бизнес никак не пострадает, в принципе :)
Думаю, секрет ненапряжной работы №1 — обозримый размер проекта. Если весь проект понимаешь и хорошо ориентируешься, то и всё, что с ним связано, тоже понимать легко. На большем проекте работать не хотел бы. Мне нравится, что я могу сдесь сделать практически всё, что угодно. А быть винтиком в машине, ковырять всё время какой-то один модуль — фу.
У меня бывали «завалы», когда за 1-2 дня приходило много багрепортов. Я просто открывал файлик TODO.txt и записывал, чтоб не забыть. За пару дней всё делал. А уж если что-то не могу сделать (например, сложность задачи несообразна выгоде), то записываю в Jira «на потом», понимая, что потом, вероятно, никогда не наступит.
Думаю, секрет ненапряжной работы №1 — обозримый размер проекта. Если весь проект понимаешь и хорошо ориентируешься, то и всё, что с ним связано, тоже понимать легко. На большем проекте работать не хотел бы. Мне нравится, что я могу сдесь сделать практически всё, что угодно. А быть винтиком в машине, ковырять всё время какой-то один модуль — фу.
У меня бывали «завалы», когда за 1-2 дня приходило много багрепортов. Я просто открывал файлик TODO.txt и записывал, чтоб не забыть. За пару дней всё делал. А уж если что-то не могу сделать (например, сложность задачи несообразна выгоде), то записываю в Jira «на потом», понимая, что потом, вероятно, никогда не наступит.
backlog же есть небось
Да запросто.
Клиент, с которым я знаком уже 5 лет.
Планы чего он хочет мы с ним оговорили на месяцы вперед.
Я выполняю небольшие законченные проектики, получаю по каждому из них денежку.
Никаких рисков.
ТЗ в этом случае — излишние расходы.
Клиент, с которым я знаком уже 5 лет.
Планы чего он хочет мы с ним оговорили на месяцы вперед.
Я выполняю небольшие законченные проектики, получаю по каждому из них денежку.
Никаких рисков.
ТЗ в этом случае — излишние расходы.
В большинстве случаев на моей практике требование с заказчика ТЗ означает желание разработчика снять с себя ответственность за принятые им же технические решения. Заказчик, как правило, не обладает достаточной технической экспертизой, чтобы не то чтобы составить, а даже понять нормальное ТЗ. Для работы с таким заказчиком для уменьшения числа конфликтных ситуаций лучше работать со списками функциональных и нефункциональных требований, сценариев использования, тесткейсов и т. п. на языке предметной области и понятных заказчику терминов UI, пряча от него всю техническую кухню, кроме тех технических требований, с которым он пришёл сам и тех, которые будут определять среду исполнения разрабатываемой системы: ОС, рантайм, готовые сервисы типа СУБД и веб-серверов…
UFO just landed and posted this here
Программист на зарплате (версия 7). Прямо сейчас работаю над задачей для бухгалтерии. Бухгалтерия это особая каста в нашей компании, так сказать «приоритет номер ноль» (версия 5). Писать ТЗ бухи просто не в состоянии, объяснять тоже (версия 6, 8 и 9).
Делать надо срочно, без ТЗ и без внятного объяснения. Спасает лишь опыт и капелька магии.
Делать надо срочно, без ТЗ и без внятного объяснения. Спасает лишь опыт и капелька магии.
Нет в голосовалке варианта — Я аналитик и вообще не понимаю этих людей, как они работают без ТЗ:)
То с чем приходил заказчик, обычно не читал даже сам заказчик. А то что писали совместно не читали программисты, потому что "вроде и так было понятно". В итоге спасали только спринты и демо. Проекты не большие на 2-3 месяца на 3 программистов, думаю дело в этом. В сроки и в бюджет влезали.
Менеджер очень торопился срубить бабла, и отдал клиенту договор на подпись. А про ТЗ тупо забыл, хотя оно было готово.
Пишу CRM для управляющей компании с несколькими подразделениями с немного разными, но смежными сферами деятельности. ТЗ были когда-то написаны со слов, тогда еще, заказчика и утверждены. Но спустя примерно год появились новые требования, которые ломают, казалось бы, продуманную структуру некоторых компонентов всей системы. Сейчас работаю без ТЗ, но раз в неделю провожу встречи с руководством, где мы обсуждаем возникшие проблемы и составляем дальнейший план действий по их разрешению, чтобы не плодить костыли и безболезненно внедрять новшества. Пока получается.
Работаю без ТЗ постоянно (интернет магазины и прочие мелкие проекты) применяя вместо него принцип «Каши из топора».
Продаю сначала клиенту недорого некоторый оговоренный с ним крайне базовый функционал(движок трех-страничник) плюс типовой дизайн с правом поменять его один раз (тщательно описав что именно он хочет изменить). Все что сверх него — за отдельную плату.
Проблемы с нарастающими хотелками заказчиков решаются очень просто — введением отдельной платы за каждую отдельно взятую хотелку. При большом количестве изначальных хотелок, отличающихся от базового функционала, работаю на окладе.
Продаю сначала клиенту недорого некоторый оговоренный с ним крайне базовый функционал(движок трех-страничник) плюс типовой дизайн с правом поменять его один раз (тщательно описав что именно он хочет изменить). Все что сверх него — за отдельную плату.
Проблемы с нарастающими хотелками заказчиков решаются очень просто — введением отдельной платы за каждую отдельно взятую хотелку. При большом количестве изначальных хотелок, отличающихся от базового функционала, работаю на окладе.
Я вот в реальной жизни ни разу не встречал ТЗ, за ~9 лет работы. Правда я обычно не фрилансю, а работаю на какую-нибудь одну компанию над собственными проектами.
А как же вам задачи ставят? Устно?
Как работу принимают?
Как работу принимают?
Зависит от компании (за 9 лет поменял несколько). Были таск-трекеры, но чаще всего это устно/email/skype и т.д.
В лучшем случае – есть описание фичи + нарисованный дизайн (работаю, в основном, по фронтенду) или готовое API, которое надо прикрутить. На последнем месте (2.5 года, удалёнка с почасовой ставкой) – чаще всего просто краткое описание конечной цели.
В одной предыдущей компании начинал проект с нуля на роли главного по фронтенду – но там за мной оставались технические решения, визуальная часть рисовалась дизайнерами, а логика – результат совместных обсуждений.
"Как принимают" – по принципу "работает ли нужная фича". :-)
в моем случае вариант «9 — заказчик не знает как должно быть» еще расширяется тем, что он не знает как вообще может быть (т.е. когда я после презентации очередной части говорю «а тут я еще вот так сделал» у них обычно круглые глаза и вопрос «а что, можно и так? » :) ) + у заказчика еще есть начальство, которое тоже не знает как оно должно работать + конечные пользователи, которые могут сказать только как ПО ДРУГОМУ это должно работать :)
т.е. процесс такой — поверхностные требования — лепка работающего прототипа — презентация — сбор изменений (а по сути настоящих требований) и очень часто уже поздно писать ТЗ, т.к. сделать быстрее… (это вот наверное упомянутая в другом варианте лень), но если решение сложное — то технический док таки создается… потом… :)
т.е. процесс такой — поверхностные требования — лепка работающего прототипа — презентация — сбор изменений (а по сути настоящих требований) и очень часто уже поздно писать ТЗ, т.к. сделать быстрее… (это вот наверное упомянутая в другом варианте лень), но если решение сложное — то технический док таки создается… потом… :)
в моем случае вариант «9 — заказчик не знает как должно быть» еще расширяется тем, что он не знает как вообще может быть (т.е. когда я после презентации очередной части говорю «а тут я еще вот так сделал» у них обычно круглые глаза и вопрос «а что, можно и так? » :) )
Заказчик тебя и нанимает как квалифицированного специалиста, чтобы ты ему все рассказал и сделал.
Ты и сам, когда обращаешься к специалисту за услугами в сфере, в которой ты не в зуб ногой — будешь только рад, если он тебе расскажет, а что вообще можно тут делать…
UFO just landed and posted this here
Добавлю МОЩНОСТИ в пункт 1.
Ушедший заказчик пойдет к другому разработчику и будет выносить мозг ему,
а ты в это время будишь меньше парится с другим вменяемым господином.
Итог:
Конкурент может потерять время и вообще ничего не заработать! — 50% / 50%
Ты — имеешь больше вероятность заработать и меньше парится — 90% / 10%
Имеет смысл для конкурентной борьбы.
Ушедший заказчик пойдет к другому разработчику и будет выносить мозг ему,
а ты в это время будишь меньше парится с другим вменяемым господином.
Итог:
Конкурент может потерять время и вообще ничего не заработать! — 50% / 50%
Ты — имеешь больше вероятность заработать и меньше парится — 90% / 10%
Имеет смысл для конкурентной борьбы.
Ещё версия: в начале ТЗ было, но потом как-бы нет. ТЗ это основа, а дальше всё начинает меняться, и дорабатывать полноценное ТЗ уже не стали, просто отказались от него, когда старое себя изжило (часть реализовали/часть передумали). Стори есть, таски есть, но чёткого видение конечного продукта уже ни у кого нет, тем более, что его нет на бумаге.
Какой-то мир розовых пони, где заказчики знают чего хотят, осознают свои ошибки и принимают на себя вину, готовы быстро согласовать необходимые документы и в срок платят, даже если то, что получилось совсем не то, что нужно но соответствует тз, да и еще без проблем готовы примерно 1/3 заплатить за обследование и составление тз( а то и половину и вперед без гарантии результата ).
Часто наблюдаю работу небольшими итерациями, без ТЗ но с приблизительным описание результата( без формального документооборота, например по email ).
Часто наблюдаю работу небольшими итерациями, без ТЗ но с приблизительным описание результата( без формального документооборота, например по email ).
Этот «розовый мир» у вас будет до первой судебной разборки, до первой разборки «ты сделал не то что мы хотели».
До первой разборки типа:
— ты сломал, что уже работало!
— Но вы же сами в этой итерации заказали такую фичу. А она вступила в коллизию с прошлогодней.
— а ты чего не сказал?
— а я думал вы подумали и осознанно заказали.
— возвращай все в зад… денег не будет…
Все рано и поздно приходят к нормальному вменяемому ТЗ.
Вопрос его создания и управления им — это другая и интересная тема :)
До первой разборки типа:
— ты сломал, что уже работало!
— Но вы же сами в этой итерации заказали такую фичу. А она вступила в коллизию с прошлогодней.
— а ты чего не сказал?
— а я думал вы подумали и осознанно заказали.
— возвращай все в зад… денег не будет…
Все рано и поздно приходят к нормальному вменяемому ТЗ.
Вопрос его создания и управления им — это другая и интересная тема :)
Чтобы судебную разборку учинить какой то документ о взаимных обязанностях иметь надо… например ТЗ.
а для разборки «ты сделал не то что мы хотели» какой то документ в котором они пишут что именно они хотели, причем так, что это не допускает толкования по которому вы все сделали. Так что на мой взгляд nApoBo3 таки прав- небольшие итерации с согласованием по email — это наше все.
а для разборки «ты сделал не то что мы хотели» какой то документ в котором они пишут что именно они хотели, причем так, что это не допускает толкования по которому вы все сделали. Так что на мой взгляд nApoBo3 таки прав- небольшие итерации с согласованием по email — это наше все.
Вместо ТЗ — User story. Часть от клиентов, часть сам завожу. Для больших изменений завожу RFC и рассылаю тем, чьи комvентарии могут быть полезными. На основе RFC рисуются change requests.
Пишу ТЗ с 2009 года =) Были проекты, в которых написание ТЗ потопило проект (пока написали, утвердили со всеми, поменялось законодательство и другие правила игры). Были проекты, в которых концепт, полученный «на коленке» в процессе переговоров на первой встрече (не написание ТЗ), в процессе сильно отличался от необходимого решения и сей момент тоже потопил проект.
А вывод один и как везде: важен компромисс в % потраченного времени на разжевывание ТЗ по отношению к его реализацию (этапов больше, два для простоты). Вопрос должен звучать не «Надо ТЗ или нет?», а «В конкретном проекте какую степень детализации мы себе можем позволить для победы». Некоторые задачи понятны с первого взгляда (исправление очевидных багов, например). А некоторые требует проработку ТЗ на всех эшелонах: vision, спецификация функциональных, спецификация нефункциональных, спецификация системных требований, план внедрения и тд тп.
Эмпирически мы на подсознательном уровне понимаем, какую степень проработки ТЗ в своих проектах применять (ТЗ как… опаприкрывательство, как план для клиента, разработчика, тестировщика, внедренца и тд). Но общих правил тут наверное нет.
А вывод один и как везде: важен компромисс в % потраченного времени на разжевывание ТЗ по отношению к его реализацию (этапов больше, два для простоты). Вопрос должен звучать не «Надо ТЗ или нет?», а «В конкретном проекте какую степень детализации мы себе можем позволить для победы». Некоторые задачи понятны с первого взгляда (исправление очевидных багов, например). А некоторые требует проработку ТЗ на всех эшелонах: vision, спецификация функциональных, спецификация нефункциональных, спецификация системных требований, план внедрения и тд тп.
Эмпирически мы на подсознательном уровне понимаем, какую степень проработки ТЗ в своих проектах применять (ТЗ как… опаприкрывательство, как план для клиента, разработчика, тестировщика, внедренца и тд). Но общих правил тут наверное нет.
Были проекты, в которых написание ТЗ потопило проект (пока написали, утвердили со всеми, поменялось законодательство и другие правила игры)
Как раз оно спасло проект :)
Сначала бы просадили бабло на реализацию, а потом все равно пришлось бы переделывать :) Судя по потраченным срокам на ТЗ окупиться бы не успел проект :)
Со степень детализации — это верно.
Ну я немного не довел суть истории. Можно год писать ТЗ на реализацию, просто к моменту окончания — мир поменялся и пиши снова. А в реальности надо MVP как можно раньше выпустить, в процессе получать обратную связь как можно раньше(ну и иметь серьезных прогеров/архитекторов для требуемой гибкости продукта). Т.е. этот год, ну 10 месяцев, можно иметь некий продукт с выхлопом пользы для заказчика и постепенным наращиванием «мяса».
Это не вопрос ТЗ. Это вопрос выбора метологии выполнения проекта.
То, что вы описали в «пессимистичном случае» — это классический недостаток водопада.
То, что вы описали в «оптимистичнос случае» — это классическое достоиство Agile методологий.
Что служит выбором между методологиями? тоже что и всегда: время-ресурсы-деньги.
Но ни одна из этих метологий не исключает ТЗ. Просто она перепихивает их на разных участниках. И всегда! присутсвует связка — Хотелка-Приемка. Даже в врырожденном случае «без ТЗ» экстремального программирования — у вас будут карточки, а за спиной стоять «носитель знания» который тут-же показывает «пальцем» как сделать или поправить (причем риски накосячить лежат полностью на «носителе знания»).
Считайте что РИСК + ТЗ =100% Увеличив одно, вы понимажете другое.
То, что вы описали в «пессимистичном случае» — это классический недостаток водопада.
То, что вы описали в «оптимистичнос случае» — это классическое достоиство Agile методологий.
Что служит выбором между методологиями? тоже что и всегда: время-ресурсы-деньги.
Но ни одна из этих метологий не исключает ТЗ. Просто она перепихивает их на разных участниках. И всегда! присутсвует связка — Хотелка-Приемка. Даже в врырожденном случае «без ТЗ» экстремального программирования — у вас будут карточки, а за спиной стоять «носитель знания» который тут-же показывает «пальцем» как сделать или поправить (причем риски накосячить лежат полностью на «носителе знания»).
Считайте что РИСК + ТЗ =100% Увеличив одно, вы понимажете другое.
На всякий случай скажу, что у меня все оке, все схвачено и нет проблем на этом поприще =) Зашел так сказать точку зрения высказать.
Человека из топика разоряется, что «Как так, почему без ТЗ существует разработка». А на самом деле ТЗ ведь не цель, главное результат. Есть результат при минимуме рисков — молодцы. И не важно, было отдельное ТЗ и этап его построения до начала проекта или нет.
Человека из топика разоряется, что «Как так, почему без ТЗ существует разработка». А на самом деле ТЗ ведь не цель, главное результат. Есть результат при минимуме рисков — молодцы. И не важно, было отдельное ТЗ и этап его построения до начала проекта или нет.
Своя версия: Без ТЗ за долю в проекте. После этого ТЗ как правило всё равно появляется.
Проблема в том, что разработчик работает не с ТЗ, а с клиентом. «Надо лечить больного, а не болезнь». Если клиент не доволен, то вы будете как котенка тыкать его в ТЗ? Вам один раз заплатят (если заплатят) и вы потеряете клиента. Главное чтобы клиент был доволен и заплатил, а дальше как вы все организуете и реализовываете — хоть ТЗ, хоть документом «Стра-те-гия», хоть на словах договорились — без разницы.
Главным образом пункт 7 — программист на зарплате.
Но есть нюансы)) Немаленькое предприятие пищевой отрасли. Я, можно сказать, разработчик почти полного цикла.))
Типичный кейс. После очередной поездки за бугор подходит руковод и рассказывает, какую супер-пупер установку он там видел и показывает фотки. И говорит, что нам нужна такая-же, но импортная стоит в районе сотни тонн валюты, поэтому мы сделаем сами. Так как это уже не первый раз, вздыхаю и говорю — давайте сделаем, фигли делов-то, пишите ТЗ. Через неделю-другую получаю изрисованный от руки лист формата А1...0, склееный из различных листов с записями докторским почерком. После изучения манускрипта и пытки технологов рождается ТЗ, которое принимается редакции в пятой.
ТЗ, как известно, это больше половины работы, поэтому дальше уже проще… Рождаю схемы компоновочную, электрическую, спецификацию оборудования, параллельно механики проектируют свою часть. Пока закупаются комплектующие, пишу программу, по приходу оборудования всё собирается в кучу.
К тому времени, как установка обретет законченный вид, ТЗ уже основательно переработано и конструкция требует переделки…
Всё таки мы доживаем до ПНР. После пробных запусков выясняется, что требуются «некоторые» доработки.
В конце концов, установка запускается, обучается персонал, но доработки тянутся ещё достаточно долго, параллельно с ещё двумя-тремя параллельными проектами, находящимися на разных стадиях.
Наверное, повествование можно растянуть на целый пост, но пока не чувствую достаточно сил )))
Но есть нюансы)) Немаленькое предприятие пищевой отрасли. Я, можно сказать, разработчик почти полного цикла.))
Типичный кейс. После очередной поездки за бугор подходит руковод и рассказывает, какую супер-пупер установку он там видел и показывает фотки. И говорит, что нам нужна такая-же, но импортная стоит в районе сотни тонн валюты, поэтому мы сделаем сами. Так как это уже не первый раз, вздыхаю и говорю — давайте сделаем, фигли делов-то, пишите ТЗ. Через неделю-другую получаю изрисованный от руки лист формата А1...0, склееный из различных листов с записями докторским почерком. После изучения манускрипта и пытки технологов рождается ТЗ, которое принимается редакции в пятой.
ТЗ, как известно, это больше половины работы, поэтому дальше уже проще… Рождаю схемы компоновочную, электрическую, спецификацию оборудования, параллельно механики проектируют свою часть. Пока закупаются комплектующие, пишу программу, по приходу оборудования всё собирается в кучу.
К тому времени, как установка обретет законченный вид, ТЗ уже основательно переработано и конструкция требует переделки…
Всё таки мы доживаем до ПНР. После пробных запусков выясняется, что требуются «некоторые» доработки.
В конце концов, установка запускается, обучается персонал, но доработки тянутся ещё достаточно долго, параллельно с ещё двумя-тремя параллельными проектами, находящимися на разных стадиях.
Наверное, повествование можно растянуть на целый пост, но пока не чувствую достаточно сил )))
А почему нет вариантов — работал с ТЗ и расстроен?
Как заказчик работал с ТЗ и очень грустил.
Вписать в ТЗ требование к качеству кода или тестированию фактически невозможно.
Если делать деспотично — будет плохой код или недостаточная полнота тестирования, акт не подпишем, пока не переделаете за свои средства — то найти подрядчика практически нереально.
Если в рекомендательном плане, то кончается всегда одним и тем же:
— У вас тут костыли и велосипеды, код будет трудно поддерживать, можно было сделать эффективней и короче.
— Это всё субъективно.
— Но PEP8 можно же было хотя бы во внешних интерфесах соблюдать? Мы ж просили.
— Требования соблюдены — подписывайте акт. А на рекомендации мы клали с прибором.
— Всё протестировали?
— Конечно.
— Вот на таком простом тесте у вас возникает исключение.
— В реальности такого не будет, но если очень надо, за отдельную плату можем и этот синтетический тест приобщить.
В ситуации программист на зряплате, без ТЗ, на ревью можно отфутболивать, пока код не будет вылизан, при этом отсутствие умения делать сразу хорошо будет сказываться на общем вознаграждение этого программиста.
Как исполнитель работал с ТЗ, расстроен.
ТЗ писали тратя свои силы, пытаясь угадать, что хочет заказчик. Проще был бы сразу код писать и переделывать по результатам отзыва.
ТЗ пришлось переписывать несколько раз за контракт (контракт такую возможность предусматривал), но…верёвочки рвались разные, а Пяточёк было один и тот же. Очень трудно вписать в ТЗ накладные расходы, связанные с отладкой стенда заказчки; штрафы за простой, пока заказчик правит свою сторону, в случае «хороших отношений» вписать просто невозможно.
В итоге ТЗ как бы есть на него потрачены силы, но занимаемся всем чем угодно, но не им. Проще было бы без него.
Как заказчик работал с ТЗ и очень грустил.
Вписать в ТЗ требование к качеству кода или тестированию фактически невозможно.
Если делать деспотично — будет плохой код или недостаточная полнота тестирования, акт не подпишем, пока не переделаете за свои средства — то найти подрядчика практически нереально.
Если в рекомендательном плане, то кончается всегда одним и тем же:
— У вас тут костыли и велосипеды, код будет трудно поддерживать, можно было сделать эффективней и короче.
— Это всё субъективно.
— Но PEP8 можно же было хотя бы во внешних интерфесах соблюдать? Мы ж просили.
— Требования соблюдены — подписывайте акт. А на рекомендации мы клали с прибором.
— Всё протестировали?
— Конечно.
— Вот на таком простом тесте у вас возникает исключение.
— В реальности такого не будет, но если очень надо, за отдельную плату можем и этот синтетический тест приобщить.
В ситуации программист на зряплате, без ТЗ, на ревью можно отфутболивать, пока код не будет вылизан, при этом отсутствие умения делать сразу хорошо будет сказываться на общем вознаграждение этого программиста.
Как исполнитель работал с ТЗ, расстроен.
ТЗ писали тратя свои силы, пытаясь угадать, что хочет заказчик. Проще был бы сразу код писать и переделывать по результатам отзыва.
ТЗ пришлось переписывать несколько раз за контракт (контракт такую возможность предусматривал), но…верёвочки рвались разные, а Пяточёк было один и тот же. Очень трудно вписать в ТЗ накладные расходы, связанные с отладкой стенда заказчки; штрафы за простой, пока заказчик правит свою сторону, в случае «хороших отношений» вписать просто невозможно.
В итоге ТЗ как бы есть на него потрачены силы, но занимаемся всем чем угодно, но не им. Проще было бы без него.
Вписать в ТЗ требование к качеству кода или тестированию фактически невозможно.
А в чем проблема? включите в договор не только передачу решения, но и тестовых сценариев и протоколов тестирования.
Есть инструменты по оценке кода. Если вам это надо — просите протоколы :)
Только будьте готовы оплатить это :) Любой каприз за ваши деньги :)
А на рекомендации мы клали с прибором
Серия стандартов ISO на это есть. включаете в контракт, в акт включаются протоколы аудита.
то найти подрядчика практически нереально.велкам :))
ТЗ писали тратя свои силы, пытаясь угадать, что хочет заказчик.
Забавно. ТЗ это не «ПЫТАЛИСЬ УАГАДАТЬ»!!! это «ЧТО НУЖНО». Хочу Х, проверяется Y. Фактически не имея ТЗ вы не можете ни бюджет, ни ресурсы распланировать для проекта! Фактически без ТЗ у вас НЕТ КОНТРАКТА!
Очень трудно вписать в ТЗ накладные расходы, связанные с отладкой стенда заказчки; штрафы за простой, пока заказчик правит свою сторону, в случае «хороших отношений» вписать просто невозможно.
Потому что бюджет к ТЗ не имеет отношение. это отдельный документ. и делается на основе ТЗ и после ТЗ.
А вопрос «включить» — это управление рисками. На это все есть своя «магия», ее нужно просто делать.
По первому примеру не вижу большой проблемы: довольно скоро с таким исполнителем просто никто не станет работать.
— Здрасьте, мы такие-то, может, посотрудничаем?
— А, те самые, у которых «всё субъективно» и «на рекомендации мы клали с прибором»? Наслышаны, прощайте.
— Здрасьте, мы такие-то, может, посотрудничаем?
— А, те самые, у которых «всё субъективно» и «на рекомендации мы клали с прибором»? Наслышаны, прощайте.
Или другой вариант: эти ребята знают, что происходит в коде, а другие нет. В итоге получается такой милый vendor lock-in.
Плюс не забывайте — если подрядчик сэкономил на разработчиках/тестировщиках, то он может давить ценой.
Как пример из жизни — Tata Consultancy Services.
Плюс не забывайте — если подрядчик сэкономил на разработчиках/тестировщиках, то он может давить ценой.
Как пример из жизни — Tata Consultancy Services.
Четкое детальное ТЗ просто жизненно необходимо для взрослых проектов, когда:
Но бывают также случаи, когда излишне громоздкое ТЗ больше вредит, чем помогает:
Примеры из жизни:
- Договор предусматривает ответственность за срыв сроков или несоответствие ожиданий клиента конечному результату.
- Заказчик скандальный, капризный или имеет за спиной судебные тяжбы с иными исполнителями. Либо клиент новый и информации о нем недостаточно.
- Заказчик действительно может более-менее точно сформулировать свои пожелания.
- Разработка ведется группой разработчиков, каждый из которых может взять на себя конкретный пункт ТЗ. Очень удобно, что разработчик четко понимает зону своей ответственности и объем работ без лишних объяснений.
Но бывают также случаи, когда излишне громоздкое ТЗ больше вредит, чем помогает:
- на его составление и проработку тратится время, зачастую немалое. При этом клиент не хочет вникать в технические нюансы и вообще, проект ему нужен исключительно как затычка: «Чувак, просто возьми мои деньги и дай мне товар! Ты лучше меня знаешь, как это должно работать».
- ограничивается творческая свобода разработчика, превращая работу в набор рутинных операций. Вместо того, чтобы создать простой стандартный интерфейс за 10-15 минут, разработчик 2-3 часа читает ТЗ и реализует «фичи», которые на самом деле никому не нужны.
- упираясь рогом в ТЗ, вы не даете клиенту то, что он желает получить в результате.
Примеры из жизни:
- При разработке сайтов для банков, составление и согласование ТЗ занимало 1-2 месяца. Причем описание одного только приложения могло занимать 3-15 страниц текста с формулами и финансовыми терминами. Сложные проекты удалось грамотно разбить между пятью разработчиками на мелкие задачи и соблюсти все сроки только благодаря детальному ТЗ. Настолько детальному, что у разработчиков не появлялось дополнительных вопросов по реализации вообще.
- Когда я в одиночку пишу проекты для друзей, я обычно сразу им говорю: «Я лучше тебя знаю, что ты хочешь. Просто не мешай». ТЗ при этом я не составляю и считаю, что это существенно экономит мне время.
- Я никогда не составляю ТЗ для своих проектов — это пустая трата времени, потому как я и так знаю, чего я хочу.
- Я всегда требую ТЗ если заказчик малознакомый, но почти всегда отклоняюсь от него в угоду удобству и эргономичности продукта. Пока ни разу об этом не жалел — просто заказчик на момент составления ТЗ не знал, что так можно, пока не увидел готовую реализацию.
- Я всегда закладываю в стоимость проекта большой пакет правок, потому когда заказчик просит что-либо переделать, я абсолютно спокоен и без надобности не тыкаю его носом в ТЗ. Правки — это нормальное явление.
По-моему тематика «Без ТЗ — ад, зачем вы так?!» немного вывернута на изнанку.
Компания или фрилансер предоставляет услуги. ТЗ — это лишь часть общего бизнес-процесса. Какая разница как бизнес работает с ТЗ, если в итоге это ведет к удовлетворительным для бизнеса результатам? Т.е. идти ведь надо от целей бизнеса, а не от хотелок бизнес-аналитика.
Другой момент, если отсутствие или плохая работа с ТЗ накладывает дорогие второстепенные проблемы, все эти печальные случаи и истории о которых знает каждый разработчик. Но если без ТЗ вам плохо, то логично, что тогда стоит обратить больше внимания на работу с ТЗ? А на сколько глубоко подойти к вопросу опять же зависит от целей бизнеса и конкретной ситуации.
Вариант «Без ТЗ мы страдаем, но все равно делаем все без ТЗ» — если вы все еще на рынке, то значит не так уж и страдаете :)
Компания или фрилансер предоставляет услуги. ТЗ — это лишь часть общего бизнес-процесса. Какая разница как бизнес работает с ТЗ, если в итоге это ведет к удовлетворительным для бизнеса результатам? Т.е. идти ведь надо от целей бизнеса, а не от хотелок бизнес-аналитика.
Другой момент, если отсутствие или плохая работа с ТЗ накладывает дорогие второстепенные проблемы, все эти печальные случаи и истории о которых знает каждый разработчик. Но если без ТЗ вам плохо, то логично, что тогда стоит обратить больше внимания на работу с ТЗ? А на сколько глубоко подойти к вопросу опять же зависит от целей бизнеса и конкретной ситуации.
Вариант «Без ТЗ мы страдаем, но все равно делаем все без ТЗ» — если вы все еще на рынке, то значит не так уж и страдаете :)
Только что закончили основной этап проекта по созданию куба БЕЗ ТЗ. Некий вариант «заказчик не знает как должно быть», но с добавлением, что и исполнитель не знает, как это можно сделать. :)
Успешно.
Это был АДЪ :)
НО.
ТЗ просто не получалось написать.
Мы не смогли найти специалистов, которые обладают нужными знаниями для написания ТЗ.
Общая задача:
Надо разложить себестоимость продаж (фактически — отдельные фин проводки) на составные элементы с точностью до инвойса от поставщика товаров / услуг. Также нужны аналогичные отчеты по себестоимости, которая отнесена на конкретные партии закупленного материала на всем пути от завода до покупателя.
Куб предназначен в первую очередь для финансистов. Данные надо получать из ERP — MS Dynamics NAV. При этом данные надо ОЧЕНЬ сильно трансформировать перед загрузкой в куб.
То есть человек, который мог бы написать ТЗ, должен:
— иметь знания в области финансов (финансисты понимали, что им надо, но объяснить чистым ИТишникам не получалось)
— иметь знания, как работает MS Dynamics NAV (один из самых сложных модулей — расчет себестоимости)
— разбираться, как можно преобразовать данные в нужный формат
— разбираться в кубах (SSAS)
Найти человека, который знает что-то одно — легко. Всё вместе — нет таких (не смогли найти).
А так, что один умеет читать, а другой — писать — не получается. Слишком много всего надо учесть и все вещи слишком взаимосвязаны…
Например, нельзя проектировать куб, не понимая, какие данные и в каком формате можно получить из системы. А не разбираясь в финансах, нельзя решить — подойдет некая структура куба для получения нужных отчетов или нет.
Было весело… :)))
Успешно.
Это был АДЪ :)
НО.
ТЗ просто не получалось написать.
Мы не смогли найти специалистов, которые обладают нужными знаниями для написания ТЗ.
Общая задача:
Надо разложить себестоимость продаж (фактически — отдельные фин проводки) на составные элементы с точностью до инвойса от поставщика товаров / услуг. Также нужны аналогичные отчеты по себестоимости, которая отнесена на конкретные партии закупленного материала на всем пути от завода до покупателя.
Куб предназначен в первую очередь для финансистов. Данные надо получать из ERP — MS Dynamics NAV. При этом данные надо ОЧЕНЬ сильно трансформировать перед загрузкой в куб.
То есть человек, который мог бы написать ТЗ, должен:
— иметь знания в области финансов (финансисты понимали, что им надо, но объяснить чистым ИТишникам не получалось)
— иметь знания, как работает MS Dynamics NAV (один из самых сложных модулей — расчет себестоимости)
— разбираться, как можно преобразовать данные в нужный формат
— разбираться в кубах (SSAS)
Найти человека, который знает что-то одно — легко. Всё вместе — нет таких (не смогли найти).
А так, что один умеет читать, а другой — писать — не получается. Слишком много всего надо учесть и все вещи слишком взаимосвязаны…
Например, нельзя проектировать куб, не понимая, какие данные и в каком формате можно получить из системы. А не разбираясь в финансах, нельзя решить — подойдет некая структура куба для получения нужных отчетов или нет.
Было весело… :)))
Работать без ТЗ — тяжело, но иногда трудозатраты по ТЗ сравнимы с затратами на финальный код и в таких случаях код = ТЗ.
Например для небольшого отчета мне проще после общего описания хотелок сразу написать тестовый вариант. После этого все смотрят на отчет с живыми данными (это часто важно) и озвучивают дополнительные пожелания. Часть пожеланий сразу отклоняется, остальные реализовываются.
Написание ТЗ в таких случаях — лишняя работа. Ведь для грамотного ТЗ всё равно надо проанализировать структуру данных — что и в каком виде можно получить. То есть фактически для написания ТЗ надо создать отчет :)
Написание ТЗ в таких случаях — лишняя работа. Ведь для грамотного ТЗ всё равно надо проанализировать структуру данных — что и в каком виде можно получить. То есть фактически для написания ТЗ надо создать отчет :)
Дополню — написание именно «формального» ТЗ в таких ситуациях является лишним.
ТЗ пишется, только в неявном виде.
Для отчета в качестве ТЗ выступает сам отчет (тестовая версия) + пожелания по добавлению / изменению полей.
Или это может быть тестовая версия кода, который реализует некую относительно простую функциональность + пожелания пользователей. Но с кодом сложнее — если может затронуть другие модули, то очень желательно написать формальное ТЗ.
ТЗ пишется, только в неявном виде.
Для отчета в качестве ТЗ выступает сам отчет (тестовая версия) + пожелания по добавлению / изменению полей.
Или это может быть тестовая версия кода, который реализует некую относительно простую функциональность + пожелания пользователей. Но с кодом сложнее — если может затронуть другие модули, то очень желательно написать формальное ТЗ.
Прекрасное продолжение прекрасной темы, спасибо. Из опыта моей компании могу сказать что нам удавалось построить работу без ТЗ таким образом, что все в итоге остались довольны. Сразу скажу, что клиент, взятый в качестве примера — это не мелекий стартап, а огромная немецкая(!) компания, старающаяся внедрять у себя принципы Agile-thinking, которые в понимании компании-заказчика делают ТЗ не только ненужным, но и вредным. Проект был суровым энтерпрайсом — Data Warehousing, ETL, MDM и Metadata. Т.е. области, в которых наличие не просто ТЗ, но детального системного анализа считается необходимым.
Решение было очень простым — чистый time&materials, почасовая ставка (близкая к потолочной, но без всякого умножения на три). Разумеется, люди которые работали на клиента были весьма опытными разработчиками, полностью готовыми к ситуации и относились к изменениям генеральной линии как к «любой каприз за ваши деньги».
Все закончилось хорошо :) Справедливости ради надо сказать что проект здорово облегчала рабочая атмосфера и философия клиента ( все крайне спокойно, никакого прессинга ), а так же тот факт, что суть проекта предполагала работу в основном на уровне архитектуры системы, без глубокого погружения в бизнес-логику.
Решение было очень простым — чистый time&materials, почасовая ставка (близкая к потолочной, но без всякого умножения на три). Разумеется, люди которые работали на клиента были весьма опытными разработчиками, полностью готовыми к ситуации и относились к изменениям генеральной линии как к «любой каприз за ваши деньги».
Все закончилось хорошо :) Справедливости ради надо сказать что проект здорово облегчала рабочая атмосфера и философия клиента ( все крайне спокойно, никакого прессинга ), а так же тот факт, что суть проекта предполагала работу в основном на уровне архитектуры системы, без глубокого погружения в бизнес-логику.
В ходе обсуждения у меня уже не раз складывалось чувство, что Agile и ТЗ взаимоисключают друг-друга. Никак не могу понять почему?
Какие аргументы использовал клиент, когда обосновывал вредность ТЗ для Agile?
Какие аргументы использовал клиент, когда обосновывал вредность ТЗ для Agile?
Предположу, что дурацкие «работаем без документации» проистекают из этих трех строчек:
и попыткам следовать им буквально. На мелких проектах это прокатывает…
Называется научи дурака молиться, он и лоб расшибет.
Пытался выяснить, обсудить. Все упиралось в «написано!» Прямо как религиозная секта :)
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
и попыткам следовать им буквально. На мелких проектах это прокатывает…
Называется научи дурака молиться, он и лоб расшибет.
Пытался выяснить, обсудить. Все упиралось в «написано!» Прямо как религиозная секта :)
Agile и ТЗ — богатая тема :) Можно смело писать отдельную статью-холивар :) Лично я не считаю что Agile ИСКЛЮЧАЕТ ТЗ. Не думаю что и заказчик занимал какую-то суровую позицию по поводу ТЗ в Аджайле. Просто в проекте который достался нам, ТЗ не было. И представители заказчика считали что оно и не нужно. Аджайл же. Естественно, в начале мы завели разговор о ТЗ, но проанализировав структуру команд и уровень компетенции в команде заказчиков, поняли что ТЗ ждать просто не от кого.
В результате мы максимально тщательно постарались уяснить себе желаемый результат, изучили систему и архитектурные решения системы, разработали требуемую архитектуру, составили план работ и приступили, собственно, к работам.
Так что хоть со стороны заказчика ТЗ и не было, но проектная документация с нашей стороны, которую предъявляли заказчику и согласовывали с ним, все же была :)
В результате мы максимально тщательно постарались уяснить себе желаемый результат, изучили систему и архитектурные решения системы, разработали требуемую архитектуру, составили план работ и приступили, собственно, к работам.
Так что хоть со стороны заказчика ТЗ и не было, но проектная документация с нашей стороны, которую предъявляли заказчику и согласовывали с ним, все же была :)
Agile исключает классическое ТЗ. Суть agile в этом разрезе — быстрая реакция на изменяющиеся требования заказчика. Agile — средство от ситуаций, когда пишется ТЗ, согласовывается, ведётся разработка, сдаётся, заказчик принимает, поскольку работа соответствует ТЗ, оплачивает и выкидывает, решая купить коробку или нанять своих разработчиков, которые просто будут делать то, что заказчику нужно здесь и сейчас, а не говорить «сначала мы закончим работу по ТЗ, вы её оплатите, а потом будем писать ТЗ на доработки, переделки и удаление функциональности».
Классическое — пожалуй да. ТЗ вообще — описаный вами подход может работать на несложных проектах, вроде сайта-портала. Так же для небольших бизнесов, где падение системы не приведет к остановке работы в сотнях офисов по всему миру.
Представьте «то, что заказчику нужно здесь и сейчас» на огромной энтерпрайс системе, с навороченной архитектурой, несколькими терабайтами разнородных данных в базах и таким слоем BL, что толком никто не понимает что там происходит.
Заказчик в такой ситуации может искринне хотеть такого, что при точном исполнении обрушит его бизнес. ТЗ ( хотя мы его так и не называем — поэтому я и говорю что работаем без ТЗ ) в такой ситуации у нас создается итеративно — пишется и согласовывается по маленьким кускам. И да, мы стараемся анализировать последствия записанного в документе, и возражать заказчику, если видим что он хочет ужасного.
Некий документ ( не важно как его называть) в этой ситуации необходимо хотя бы для того, чтобы в случае проблем, заказчику было сложнее заявить что это мы косорукие и все испортили — у нас остаются записи, что мы делали строго то, что хотел заказчик, и именно так, как он хотел.
Представьте «то, что заказчику нужно здесь и сейчас» на огромной энтерпрайс системе, с навороченной архитектурой, несколькими терабайтами разнородных данных в базах и таким слоем BL, что толком никто не понимает что там происходит.
Заказчик в такой ситуации может искринне хотеть такого, что при точном исполнении обрушит его бизнес. ТЗ ( хотя мы его так и не называем — поэтому я и говорю что работаем без ТЗ ) в такой ситуации у нас создается итеративно — пишется и согласовывается по маленьким кускам. И да, мы стараемся анализировать последствия записанного в документе, и возражать заказчику, если видим что он хочет ужасного.
Некий документ ( не важно как его называть) в этой ситуации необходимо хотя бы для того, чтобы в случае проблем, заказчику было сложнее заявить что это мы косорукие и все испортили — у нас остаются записи, что мы делали строго то, что хотел заказчик, и именно так, как он хотел.
Позволю себе предположить, что то, о чем вы говорите это «сервисный подход». В данном случае вы просто предоставли ресурсы под уже готовый проект. Все этапы планирования, аналитики — были на стороне Клиента. У вас же не спрашивали: Warehousing или нет. ETL или нет.
Вам просто сказали: будет Warehousing. Есть ресурсы? Сколько стоит? То, что вам позволили сначала сделать кубик А вместо кубика B — это не ваша заслуга, не ваши риски. Не взлетел кубик? ну и фиг с ним, все равно уплачено.
Если мое предположение корректно, то у вас был иной сценарий. А тут больше идет обсуждение в контекстве разработки и поставки Решения (Продукт под заказчика), причем он может его еще и не оплатить :)
Вам просто сказали: будет Warehousing. Есть ресурсы? Сколько стоит? То, что вам позволили сначала сделать кубик А вместо кубика B — это не ваша заслуга, не ваши риски. Не взлетел кубик? ну и фиг с ним, все равно уплачено.
Если мое предположение корректно, то у вас был иной сценарий. А тут больше идет обсуждение в контекстве разработки и поставки Решения (Продукт под заказчика), причем он может его еще и не оплатить :)
Да, подход, конечно, сервисный. Мы предоставляли свои знания, опыт и компетенцию в виде сервиса. И конечно, нам сказали «хотим Warehousing».
Насчет дальнейшего — все было не совсем так :) Не было со стороны заказчика ни планирования, ни аналитиков. Выше уже описал, скопирую сюда тоже:
Насчет дальнейшего — все было не совсем так :) Не было со стороны заказчика ни планирования, ни аналитиков. Выше уже описал, скопирую сюда тоже:
Просто в проекте который достался нам, ТЗ не было. И представители заказчика считали что оно и не нужно. Аджайл же. Естественно, в начале мы завели разговор о ТЗ, но проанализировав структуру команд и уровень компетенции в команде заказчиков, поняли что ТЗ ждать просто не от кого.
В результате мы максимально тщательно постарались уяснить себе желаемый результат, изучили систему и архитектурные решения системы, разработали требуемую архитектуру, составили план работ и приступили, собственно, к работам.
Так что хоть со стороны заказчика ТЗ и не было, но проектная документация с нашей стороны, которую предъявляли заказчику и согласовывали с ним, все же была :)
ИХМО жёсткое ТЗ обычно неэффективно. Часто на входе только цели проекта, критерии его успешности, сроки, примерный бюджет, ключевые требования. Не статичный список требований и их постепенная детализация через итерации — это нормально и было придумано задолго до agile.
Если фикспрайс + фиксированные сроки + сложный заказчик, то ТЗ единственное, что может хоть как-то застраховать исполнителя. Другой вопрос, на каком этапе оно появляется.
Если фикспрайс + фиксированные сроки + сложный заказчик, то ТЗ единственное, что может хоть как-то застраховать исполнителя. Другой вопрос, на каком этапе оно появляется.
еще бы увидеть ТЗ, в котором учтены все хотелки клиента и исключены неоднозначности. Любопытно было бы на него взглянуть и на потраченное кол-во часов на его составление. Бьюсь об заклад, что я найду даже в нем пару пунктов, которые я думал будут реализованы по другому.
Отличная статья! Автор, ты умница!
Работаю в геймдеве, с ТЗ не сложилось.
Обычно диалог с заказчиком такой:
З: Нам нужна камера.
Я: Ок, есть с десяток вариантов логики поведения камеры. Рассказываешь ему все варианты, попутно делаешь статью на хабр в двух частях.
З: Ок, нам нужно посмотреть все варианты, высылайте демку.
Безграмотность в геймдеве такая, что просто легче делать так как считаешь нужным, а потом переделывать, чем пытаться что-то узнать у заказчика. Это с чем-то сродни дизайну, как-бы хорошо заказчик не описал что ему нужно, всё равно дизайнер будет делать несколько вариантов, которые потом будут правится десятки раз. Тут такая-же проблема — никто не способен описать точную логику и тайминги для движения персонажа, потом всё равно придётся очень много времени потратить на доводку по смутному описанию типа: дерганное и резиновое управление.
Но план работ всегда составляю и по нему потом уже оцениваю работу вместе с заказчиком, но назвать это полноценным ТЗ лично я не могу. Ну и мелкие итерации с оплатой за каждую, спасают.
Обычно диалог с заказчиком такой:
З: Нам нужна камера.
Я: Ок, есть с десяток вариантов логики поведения камеры. Рассказываешь ему все варианты, попутно делаешь статью на хабр в двух частях.
З: Ок, нам нужно посмотреть все варианты, высылайте демку.
Безграмотность в геймдеве такая, что просто легче делать так как считаешь нужным, а потом переделывать, чем пытаться что-то узнать у заказчика. Это с чем-то сродни дизайну, как-бы хорошо заказчик не описал что ему нужно, всё равно дизайнер будет делать несколько вариантов, которые потом будут правится десятки раз. Тут такая-же проблема — никто не способен описать точную логику и тайминги для движения персонажа, потом всё равно придётся очень много времени потратить на доводку по смутному описанию типа: дерганное и резиновое управление.
Но план работ всегда составляю и по нему потом уже оцениваю работу вместе с заказчиком, но назвать это полноценным ТЗ лично я не могу. Ну и мелкие итерации с оплатой за каждую, спасают.
Начинали писать один сайт, пришел дизайнер UIX-иксперт, внес поправки и свое вИдение, и стали писать другой сайт. И так пару раз меняли тематику. Заказчик заезжал на чОрном джипе, и привозил зарплату. Все были довольны.
Какое-такое ТЗ?
Какое-такое ТЗ?
Я читал статью, лицо мое вытягивалось, вытягивалось, рот открывался все шире и шире, но потом я прочел @krivotester Бизнес-аналитик и все встало на свои места.
Классная теория, бро, жаль только что с реальным миром никаким образом не соотносится.
Классная теория, бро, жаль только что с реальным миром никаким образом не соотносится.
Эммм ну я как-то функционирую:
Тз пишутся, проекты релизятся.
Вы считаете, что это только в моем воображении?
Тз пишутся, проекты релизятся.
Вы считаете, что это только в моем воображении?
Я как раз тот самый заказчик без ТЗ. Банкет я устраиваю за свой счет. Свои деньги вынимаю из оборота.
И вот, пожалуйста, реальный пример: мне нужно оптимизировать сбор статистики. Я оставляю 20 заявок и начинается. 10 компаний откликаются через сутки и более. Значит либо работать не умеют, либо клиенты не нужны — в мусорную корзину. 5 откликнувшихся компаний предлагают мне заполнить ТЗ (читать как — работать с нашей компанией большая честь, вам для работы следует: 1… 2… 3...) — опять в корзину.
Выбирать я буду их оставшихся 5 компаний, которые вместо того чтобы тратить мое время на распросы сразу направляют мне КП, и начинают меня пинать каждый день «когда рассмотрите». Вот этим парням (я так понимаю) работа нужна. Выбирать я буду их них, и естественно выберу самое дешевое предложение и буду стараться оплатить как можно меньше и получить как можно больше функционала и доп. поддержки.
Особенно я буду стараться избегать компаний с менеджерскими прокладами между мною (Заказчиком) и непосредственным разрабочиком (Исполнителем). Почему? Потому что программисты, как правило значительно просто отжимаются на бесплатую дополнительную работу.
Да, может быть мне прийдется поменять двух, трех подрядчиков. Но по итогу я найду (точнее нашел) нужного человека который делает мне результат, за недорого и еще за бесплатно допиливает его 4 месяца, потому что у меня каждый день новые хотелки.
Почему я так делаю? Потому что банкет — за мой счет, ничего личного.
ps. в вашем проффесионализме не сомневаюсь
И вот, пожалуйста, реальный пример: мне нужно оптимизировать сбор статистики. Я оставляю 20 заявок и начинается. 10 компаний откликаются через сутки и более. Значит либо работать не умеют, либо клиенты не нужны — в мусорную корзину. 5 откликнувшихся компаний предлагают мне заполнить ТЗ (читать как — работать с нашей компанией большая честь, вам для работы следует: 1… 2… 3...) — опять в корзину.
Выбирать я буду их оставшихся 5 компаний, которые вместо того чтобы тратить мое время на распросы сразу направляют мне КП, и начинают меня пинать каждый день «когда рассмотрите». Вот этим парням (я так понимаю) работа нужна. Выбирать я буду их них, и естественно выберу самое дешевое предложение и буду стараться оплатить как можно меньше и получить как можно больше функционала и доп. поддержки.
Особенно я буду стараться избегать компаний с менеджерскими прокладами между мною (Заказчиком) и непосредственным разрабочиком (Исполнителем). Почему? Потому что программисты, как правило значительно просто отжимаются на бесплатую дополнительную работу.
Да, может быть мне прийдется поменять двух, трех подрядчиков. Но по итогу я найду (точнее нашел) нужного человека который делает мне результат, за недорого и еще за бесплатно допиливает его 4 месяца, потому что у меня каждый день новые хотелки.
Почему я так делаю? Потому что банкет — за мой счет, ничего личного.
ps. в вашем проффесионализме не сомневаюсь
Очень вас понимаю, у меня много клиентов с такой идеологией.
Оказывается, что если отправляешь в компанию вменяемое ТЗ, то и отвечают быстрее и цены ниже, т.к. разработчики белые пятна закладывают в риски.
Банкет, как вы правильно заметили, за ваш счет и если кто-то хочет платить за дополнительные риски, то обращается в страховую компанию, а не к разработчикам -)
Оказывается, что если отправляешь в компанию вменяемое ТЗ, то и отвечают быстрее и цены ниже, т.к. разработчики белые пятна закладывают в риски.
Банкет, как вы правильно заметили, за ваш счет и если кто-то хочет платить за дополнительные риски, то обращается в страховую компанию, а не к разработчикам -)
Зависит от объема/характера ваших задач.
Возможно, на ваших конкретных задачах, можно и без ТЗ вполне.
Например, на мелких задачах.
Но, как правило, если для вас важно в том числе и сэкономить деньги — именно ТЗ как раз и позволяет вам это сделать.
Возможно, на ваших конкретных задачах, можно и без ТЗ вполне.
Например, на мелких задачах.
Но, как правило, если для вас важно в том числе и сэкономить деньги — именно ТЗ как раз и позволяет вам это сделать.
Для меня важно платить за результат, а не за фитнес.
Все остальное с дисконтом в 99,5%.
Все остальное с дисконтом в 99,5%.
Ну то есть для вас важно минимизировать риски неполучения результата.
Нужно отдавать себе отчет, что при этом в денежном эквиваленте вы сильно переплачиваете. Так как исполнитель в этом случае тоже закладывает свои риски в стоимость работ, подробнее об этом написано тут: https://habrahabr.ru/post/315624/#comment_9952610
Но, фактически, лично для вас эта переплата является более рациональной, чем риск полной потери всех денег по проекту в случае его не выполнения.
Тоже разумно.
P.S.:
У меня вопрос (риторический) — где вы таких исполнителей берете, что так шугаетесь невыполнения взятых ими обязательств.
Нужно отдавать себе отчет, что при этом в денежном эквиваленте вы сильно переплачиваете. Так как исполнитель в этом случае тоже закладывает свои риски в стоимость работ, подробнее об этом написано тут: https://habrahabr.ru/post/315624/#comment_9952610
Но, фактически, лично для вас эта переплата является более рациональной, чем риск полной потери всех денег по проекту в случае его не выполнения.
Тоже разумно.
P.S.:
У меня вопрос (риторический) — где вы таких исполнителей берете, что так шугаетесь невыполнения взятых ими обязательств.
Ну то есть для вас важно минимизировать риски неполучения результата.
При чем тут риск менеджмент? Кстати в российском страховании я потерял 7 лет жизни и более-менее понимаю как все работает в этом грязненьком бизнесе. Риск-менеджмент и российское страхование (даже в западных франшизах) это просто разные категории.
Мне важно платить за результат. Я могу и не получить результата — это жизнь. Просто не хочу платить за «ну мы же много работали, кто же знал что <причина, которая мне не интересна>».
Это и есть риски. Не страховые, а обычные такие рядовые предпринимательские риски.
Общепринятый термин.
Непонятно почему вы считаете, что этот термин только в страховом деле употребим.
Общепринятый термин.
Непонятно почему вы считаете, что этот термин только в страховом деле употребим.
Объясните, пожалуйста, какие риски я несу оплачивая результат только при увеличении моей товарной маржи? Если маржа не увеличится — я не плачу. Увеличится — плачу. Где риск?
Ваша маржа, нафиг никому не сдалась :) Это друга форма отношений.
Вы покупатете сервис, что вы будете с ним делать — это только ваша проблема.
Купили и хвастаетесь своему коту, или продаете через него аламазы — это только ваша проблема и заслуга.
Если вы получили услугу с отсрочкой платежа, вам фактически сделали «товарный кредит». Кредит стоит денег :) Хотя бы курсовые риски и инфляцию, которые будут заложены, на ваш платеж, который пойдет на оплату облака Гугл/Амазон/ и т.д. :) А еще добавят вам зарплату того парня, что будет спрашивать у вас когда заплатите.
А поскольку вы не показали серьезность намерений, то вам могут сделать «вот прямо сейчас» не заложив никаких точек расширения или роста и дальнейшие доработки вам будут стоить не 5 часов, а 10.
Если вы сделали по предоплате: вам могут сделать скидку просто потому, что вы показали серьезность ваших намерений к работе.
Вам могут просто предложить решение, которое будет, например, в облаке процентов на 10% меньше жрать ресурсов. доработка будет делать не 10 часов, а 5, потому что человек вам бесплатно заложил «точки расширения».
Сделал на последней версии движка БД, а не на том, который через год просто не будет поддерживаться и т.д.
Вы покупатете сервис, что вы будете с ним делать — это только ваша проблема.
Купили и хвастаетесь своему коту, или продаете через него аламазы — это только ваша проблема и заслуга.
Если вы получили услугу с отсрочкой платежа, вам фактически сделали «товарный кредит». Кредит стоит денег :) Хотя бы курсовые риски и инфляцию, которые будут заложены, на ваш платеж, который пойдет на оплату облака Гугл/Амазон/ и т.д. :) А еще добавят вам зарплату того парня, что будет спрашивать у вас когда заплатите.
А поскольку вы не показали серьезность намерений, то вам могут сделать «вот прямо сейчас» не заложив никаких точек расширения или роста и дальнейшие доработки вам будут стоить не 5 часов, а 10.
Если вы сделали по предоплате: вам могут сделать скидку просто потому, что вы показали серьезность ваших намерений к работе.
Вам могут просто предложить решение, которое будет, например, в облаке процентов на 10% меньше жрать ресурсов. доработка будет делать не 10 часов, а 5, потому что человек вам бесплатно заложил «точки расширения».
Сделал на последней версии движка БД, а не на том, который через год просто не будет поддерживаться и т.д.
Вам могут просто предложить решение, которое будет, например, в облаке процентов на 10% меньше жрать ресурсов. доработка будет делать не 10 часов, а 5, потому что человек вам бесплатно заложил «точки расширения».
Сделал на последней версии движка БД, а не на том, который через год просто не будет поддерживаться и т.д.
Это маловероятно.
Ведь наш заказчик выбирает самое дешевое решение,
а вещи с экономией потом в будущем — стоят денег уже сейчас.
Объясните, пожалуйста, какие риски я несу оплачивая результат только при увеличении моей товарной маржи? Если маржа не увеличится — я не плачу. Увеличится — плачу. Где риск?
В этом случае — прямо наоборот,
вы уменьшили свои риски.
Но риски возросли у разработчиков,
поэтому они запросили с вас больше бабла.
Как-то очень жалко стало вашего исполнителя. Глядя на такие истории, и впрямь задумаешься, что со стороны исполнителя ТЗ не помешает. А ещё лучше просто не связываться с хитрожопыми заказчиками, а если не получилось избежать неприятностей — выходить как можно раньше.
> программисты, как правило значительно просто отжимаются на бесплатую дополнительную работу
> который делает мне результат, за недорого и еще за бесплатно допиливает его 4 месяца
Это сработает только с достаточно простыми задачами: таких, простите за выражение, лохов можно найти только среди начинающих разработчиков. Конечно, с малой вероятностью можно наткнуться на хорошего программиста, но наивного растяпу по жизни, который решил попробовать фриланс (и этот опыт будет его первым и на многие годы последним).
Со сложными задачами скорее получится так, что вы 10 раз смените подрядчиков, но так и не получите нужного результата. В лучшем случае получится что-то еле-еле работающее из-за того, что каждаая доделка сделана грубым костылем, и в итоге уже весь проект из них и состоит, а скорее всего не получите вообще ничего работоспособного. Для таких задач опытный фрилансер с хорошей почасовой оплатой, умеющий вести переговоры и вынимать из вас ваши будущие хотелки еще до того, как вы сами их осознали, в итоге обойдется дешевле, и при этом все будет ко взаимному удовольствию.
> который делает мне результат, за недорого и еще за бесплатно допиливает его 4 месяца
Это сработает только с достаточно простыми задачами: таких, простите за выражение, лохов можно найти только среди начинающих разработчиков. Конечно, с малой вероятностью можно наткнуться на хорошего программиста, но наивного растяпу по жизни, который решил попробовать фриланс (и этот опыт будет его первым и на многие годы последним).
Со сложными задачами скорее получится так, что вы 10 раз смените подрядчиков, но так и не получите нужного результата. В лучшем случае получится что-то еле-еле работающее из-за того, что каждаая доделка сделана грубым костылем, и в итоге уже весь проект из них и состоит, а скорее всего не получите вообще ничего работоспособного. Для таких задач опытный фрилансер с хорошей почасовой оплатой, умеющий вести переговоры и вынимать из вас ваши будущие хотелки еще до того, как вы сами их осознали, в итоге обойдется дешевле, и при этом все будет ко взаимному удовольствию.
Это сработает только с достаточно простыми задачами: таких, простите за выражение, лохов можно найти только среди начинающих разработчиков. Конечно, с малой вероятностью можно наткнуться на хорошего программиста, но наивного растяпу по жизни, который решил попробовать фриланс (и этот опыт будет его первым и на многие годы последним).
Даже самые простые вещи тоже могут приносить огромные деньги прибыли.
Не могли бы Вы как-то отметить пункты, которые по Вашему мнению не соотносятся с реальным миром? может быть добавите свои сценарии из реального мира?
это не подколка, а просьба поделиться опытом :)
это не подколка, а просьба поделиться опытом :)
Пожалуйста:
1.
Это правда. Где-то до 5го (10го, 20го, нужное подставить) клиента, после чего встанет выбор — размещать резюме и начинать экстренно искать работу, снова занимать денег (хорошо если есть где) или переходить на питание духовной пищей (а если есть семья, то и их тоже на духовные харчи переводить). В этот момент как правило происходит прозрение.
2.
Что такое обосновать крупную трату: «мы подписываемся за результат X, за Y денег, если результата не будет то и платить нам не надо». Кстати вполне соотносится с 60-ти дневной задержкой по оплате оказанных услуг. Нет результата — за что платить?
3. неквалифицированные заказчики
Заказчик квалифицирован в том чтобы со своего рынка выжимать деньги. А на шаманство с разработкой у него нет, не было и не будет никогда времени. И это лучшее что есть на вашем рынке. Были бы все заказчики квалифицированы — закупались бы на фриланс биржах напрямую, а не через прокладки.
4.
После этого появляется новый разрабочик на зарплатке, который не говорит менеджерам (которые на секундочку исполняют распоряжение руководства) что им надо делать, куда идти и т.д., а делает все сам, а если что-то непонятно, то подоходит и спрашивает.
5. Богатый школьник говорит
Ну еп. Как на такое вообще можно жаловаться? Мне бы таких и побольше :)
1.
Потеря клиента лишь стимулирует активнее искать новых.
Это правда. Где-то до 5го (10го, 20го, нужное подставить) клиента, после чего встанет выбор — размещать резюме и начинать экстренно искать работу, снова занимать денег (хорошо если есть где) или переходить на питание духовной пищей (а если есть семья, то и их тоже на духовные харчи переводить). В этот момент как правило происходит прозрение.
2.
На самом деле, крупные компании не боятся крупных сумм, особенно если ты их можешь обосновать.
Что такое обосновать крупную трату: «мы подписываемся за результат X, за Y денег, если результата не будет то и платить нам не надо». Кстати вполне соотносится с 60-ти дневной задержкой по оплате оказанных услуг. Нет результата — за что платить?
3. неквалифицированные заказчики
Заказчик квалифицирован в том чтобы со своего рынка выжимать деньги. А на шаманство с разработкой у него нет, не было и не будет никогда времени. И это лучшее что есть на вашем рынке. Были бы все заказчики квалифицированы — закупались бы на фриланс биржах напрямую, а не через прокладки.
4.
Разработчик на зарплате любезно сообщает ей, что она должна
После этого появляется новый разрабочик на зарплатке, который не говорит менеджерам (которые на секундочку исполняют распоряжение руководства) что им надо делать, куда идти и т.д., а делает все сам, а если что-то непонятно, то подоходит и спрашивает.
5. Богатый школьник говорит
Я не знаю, чего хочу — предложите варианты!
Ну еп. Как на такое вообще можно жаловаться? Мне бы таких и побольше :)
неквалифицированные заказчики
К сожалению, это проблема. Отсутсвие квалификации проявляется следующим образом:
Если вы внедряете такое решение извещаете Клиента:
Вам нужно сделать следующее, что бы не было проблем (к примеру):
- Разработать политику резервирования и восстановления
- Этапы внедрения решения настоятельно! рекомендуем следующие… потому-что…
- У вас должны быть готовы справочные данные по следующим правилами потому-что
Квалифицированный клиент:
- Ок парни. вот мы тут сваяли политику. гляньте? может чего рекомендуете
- Ок парни. вот мы тут сваяли график внедрение. гляньте? может чего рекомендуете
- Ок парни. вот мы тут справочные данные. гляньте? может чего обсудим
НЕ Квалифицированный клиент:
- Фигня. у нас все есть.!
- Не ваша проблема! не первый раз.
- Да у нас 1С/ CRM / ERP. Выгрузим-загрузим. 5 минут делов. Не баитесь!
не говоря о том, что бы получить встречу с кем-то из других участников проекта клиента, огранизовать тестирование у себя и т.д.
Угадайте, в каком случае наступит #@&% когда придет время раскатывать на сервер?
И кому будут выносить мозг и как, когда у клиента сложится рабочая система?
К сожалению, это проблема.
Это рядовая часть вашей работы.
Ровно такая же часть, как и умения «натянуть оператор на константу»
Если бы заказчик сам разбирался — он бы не платил вам как квалифицированному специалисту, а платил бы как… гм… уборщице, например.
Если вас напрягают такие заказчики — идите на крупную фирму и работайте через менеджеров-постановщиков задач, а не напрямую с клиентом.
Квалифицированный клиент:
- Ок парни. вот мы тут сваяли политику. гляньте? может чего рекомендуете
- Ок парни. вот мы тут сваяли график внедрение. гляньте? может чего рекомендуете
- Ок парни. вот мы тут справочные данные. гляньте? может чего обсудим
А за что платить вам?
За погляд?
Ну это как раз хватит, чтобы хлеб был с солью.
Но без масла.
Вы не уловили сути:
Квалифицированный — будет сотрудничать, будет слушать что ему говорят, спрашивать что непонятно, докупит нужный сервис если нету. Например: Мы не умеем, сколько будет купить у вас или кого рекомендуете.
Не квалифицированный тупо забьет, на то что ему говорят пофиг платно или бесплатно. А когда получит граблями в лоб, еще и обижаться будет что ему бесплатно не исправляют и не заставили! прочитать руководтво по эксплуатации перед тем как 200 человек посадить на новую систему.
Квалифицированный — будет сотрудничать, будет слушать что ему говорят, спрашивать что непонятно, докупит нужный сервис если нету. Например: Мы не умеем, сколько будет купить у вас или кого рекомендуете.
Не квалифицированный тупо забьет, на то что ему говорят пофиг платно или бесплатно. А когда получит граблями в лоб, еще и обижаться будет что ему бесплатно не исправляют и не заставили! прочитать руководтво по эксплуатации перед тем как 200 человек посадить на новую систему.
Еще раз:
Если вы работаете с заказчиками напрямую — то выяснять ТЗ и объяснять как внедрять — это часть вашей работы.
Квалификация заказчика тут ровным счетом не причем.
Он вас потому и нанял, что в этой сфере вы более квалифицированы, чем он.
Ваше дело — просто включить надбавку в счет за эту свою доп. работу.
Если вы работаете с заказчиками напрямую — то выяснять ТЗ и объяснять как внедрять — это часть вашей работы.
Квалификация заказчика тут ровным счетом не причем.
Он вас потому и нанял, что в этой сфере вы более квалифицированы, чем он.
Ваше дело — просто включить надбавку в счет за эту свою доп. работу.
Именно что причем.
Есть куча проблем, которые следует согласовать с заказчиком, до того как…
Например:
А если у клиента уже есть какие-то ИТ решения? Тогда ты должен под них «подстроиться», что бы было Клиенту удобно.
Например: у клиента инфраструктура Оракл, а ты ему предлагаешь решения на стеке Микрософт, потому что он тебе просто не сказал про Оракл.
Один аж пищат хочет облака, другие он них шарахаются.
Третьи хотят только OpenSource решения,
У Клиента есть свои представления, как он хочет развернуть инфраструктуру.
У него уже закуплено и развернуто оборудование со специфическими конфигами, а тебя просто не допускают до него.
Я у него «гость» и я не могу ломиться в «закрытые» двери.
Например:
В одном проекте предупредили клиента письменно:
Перед развертыванием решения или внесением изменений, мы вас извещаем. Вы делаете резервную копию (нам прав не дали), и после вашего подтверждения мы разворачиваем.
Клиент подтверждает: ОК.
Развернули решение. Через два месяца звонит и требует «ремонта по гарантии». Полезли разбираться. Оказалось, что Клиент поменял менее 24 часов назад конфигурацию решения, потеряв часть своих данных. Позвонили клиенту через минут 30 и известили. Сказали что бы срочно откатил из резевной копии потому что…
Клиент сказал: ОК. буду делать.
Через два дня звонок от пользователя — что за хрень ?! почему все сломано ?!
Проверили: клиент нифига не откатил.
Начали разбираться, оказалось что клиент просто не делал резервные копии… @#@$
Вот нафига был врать «парни все ок, у нас все есть»?
Есть куча проблем, которые следует согласовать с заказчиком, до того как…
Например:
- политики безопастности. Например, он бится что украдут базы клиентов.
- юридические политки. требует, что бы все разработчики были в штате.
- бизнес-политики. никакого итеративного подхода, только хардкор! только за одну ночь и в одном контракте!
А если у клиента уже есть какие-то ИТ решения? Тогда ты должен под них «подстроиться», что бы было Клиенту удобно.
Например: у клиента инфраструктура Оракл, а ты ему предлагаешь решения на стеке Микрософт, потому что он тебе просто не сказал про Оракл.
Один аж пищат хочет облака, другие он них шарахаются.
Третьи хотят только OpenSource решения,
У Клиента есть свои представления, как он хочет развернуть инфраструктуру.
У него уже закуплено и развернуто оборудование со специфическими конфигами, а тебя просто не допускают до него.
Я у него «гость» и я не могу ломиться в «закрытые» двери.
Например:
В одном проекте предупредили клиента письменно:
Перед развертыванием решения или внесением изменений, мы вас извещаем. Вы делаете резервную копию (нам прав не дали), и после вашего подтверждения мы разворачиваем.
Клиент подтверждает: ОК.
Развернули решение. Через два месяца звонит и требует «ремонта по гарантии». Полезли разбираться. Оказалось, что Клиент поменял менее 24 часов назад конфигурацию решения, потеряв часть своих данных. Позвонили клиенту через минут 30 и известили. Сказали что бы срочно откатил из резевной копии потому что…
Клиент сказал: ОК. буду делать.
Через два дня звонок от пользователя — что за хрень ?! почему все сломано ?!
Проверили: клиент нифига не откатил.
Начали разбираться, оказалось что клиент просто не делал резервные копии… @#@$
Вот нафига был врать «парни все ок, у нас все есть»?
Я у него «гость» и я не могу ломиться в «закрытые» двери
Если вы не хотите брать себя всякие неинтересные вам риски — то первым делом вы, будучи профи, должны выцепить из заказчика все эти детали
Зубами, пытками, дубиной, сладкой вкусной сахарной ватой — да как угодно.
Но выцепить все детали.
Если вы этого не делаете, то или завышаете цену, закладывая в нее риски.
Или берете на себя все риски — но это ваше личное решение.
И никто (кроме вас) не виноват, что заказчик оказался не компетентным и вы этого не учли и не скомпенсировали узнаванием деталей/повышением цены.
Заказчик обращается к вам потому что компетентны в вашей сфере именно вы, а не он.
Иначе вы бы ему платили, а не он вам.
будучи профи, должны выцепить из заказчика все эти детали
Зубами, пытками, дубиной, сладкой вкусной сахарной ватой — да как угодно.
Но выцепить все детали.
Были интересные задачи:
- система оценки кредитных рисков для банков. Ее приемка идет по тестовым сценария. подготовленным банком. и если банк накосячит — на выходе будет фигня. Это секретная информаци и я не могу никак ее выцепить.
- Работа с госсистемами, которые имеют «гриф». Суровые люди тебе просто говорят — должно быть вот так. Хотя с точки зрения здравого смысла/ опыта это бред сумашедшего.
- Нафига мне знать обороты Большой Компании и через кого идет работа с офшорами? движуха по счетам ?
Я вынужден доверять тому, что мне сказано Клиентом, если он отказывает мне в проверке предоставленных им данных. А что бы «не попасть» вынужден защищаться юридически.
Вы в больнице подписываете форму, на что у вас есть аллергия. Если вы солгали и вам ввели опасное вам вещество, вы можете умереть. Подписанная форма снимает ответственность с врача. Люди это понимают и говорят правду. А в ИТ — нифига. Зачем ?!
Вам пломбу поставили и предупредили не есть орешки? Вы начали щелкать грецкие орешки и отрывать пиво и зуб под удаление? Вы сам себе злой буратино. А в ИТ? А зачем ?!
Мы спецы, у нас дохрена опросников и чеклистов, как не накосячить, но я не могу заставить клиента их прочитать, потому что «5 откликнувшихся компаний предлагают мне заполнить ТЗ (читать как — работать с нашей компанией большая честь, вам для работы следует: 1… 2… 3...) — опять в корзину.»
Я могу только в контрате написать «что не оговорено в ТЗ и критериях приемки, делается за отдельную плату».
И если мне Клиент солгал или не знал или не захотел сказать когда я его спрашивал, что вместо 10 человек запланированных, у него будет работать 100 — я с чистой совестью, выкачу ему счет за решение возникшей проблемы:)
Это правда. Где-то до 5го (10го, 20го, нужное подставить) клиента, после чего встанет выбор — размещать резюме и начинать экстренно искать работу, снова занимать денег (хорошо если есть где) или переходить на питание духовной пищей (а если есть семья, то и их тоже на духовные харчи переводить). В этот момент как правило происходит прозрение
Сейчас дефицит квалифицированных ИТ кадров.
При этом кто-нибудь на ваш призыв, разумеется, откликнется.
А сделать что нибудь более-менее не тривиальное, в сроки и без косяков — таких спецов нужно искать и задачи у них расписаны на недели (в лучшем случае на недели; у меня, к примеру — на пару месяцев) вперед.
Эмм ну может быть да, мы из параллельных реальностей:
1. Семья и двое детей имеется. Хвататься за каждого клиента, который будет из меня что-то отжимать как и когда ему хочется не прибыльно, пусть лучше идет к конкурентам и жрет их ресурсы -). Свой бизнес у меня с 2009-ого, полет нормальный.
2. С крупными международными компаниями сейчас работаю с четырьмя вместе с партнерами. Если пройти отбор и правильно договориться, то и предоплата возможна, и техническое задание и в целом адекват. Но на входе все как описано в статье.
3. Часто мои заказчики — разработчики программного обеспечения. Иногда выступаю мостом между разными командами разработчиков. Квалифицированные заказчики есть на рынке, а разделение труда — это нормально.
На фриланс биржу не лезут не потому что не квалифицированы, а потому что бизнес в другом.
4. Толкового разработчика найти сложно. Новый разработчик на зарплате не появляется ни завтра ни через месяц, даже на довольно простых проектах. Недавно клиенты два месяца HTML-верстальщика банального в офис искали два месяца.
5. Охмурять школьников, и в целом охмурять — не мой бизнес. Не хочу, чтобы таких было побольше.
1. Семья и двое детей имеется. Хвататься за каждого клиента, который будет из меня что-то отжимать как и когда ему хочется не прибыльно, пусть лучше идет к конкурентам и жрет их ресурсы -). Свой бизнес у меня с 2009-ого, полет нормальный.
2. С крупными международными компаниями сейчас работаю с четырьмя вместе с партнерами. Если пройти отбор и правильно договориться, то и предоплата возможна, и техническое задание и в целом адекват. Но на входе все как описано в статье.
3. Часто мои заказчики — разработчики программного обеспечения. Иногда выступаю мостом между разными командами разработчиков. Квалифицированные заказчики есть на рынке, а разделение труда — это нормально.
На фриланс биржу не лезут не потому что не квалифицированы, а потому что бизнес в другом.
4. Толкового разработчика найти сложно. Новый разработчик на зарплате не появляется ни завтра ни через месяц, даже на довольно простых проектах. Недавно клиенты два месяца HTML-верстальщика банального в офис искали два месяца.
5. Охмурять школьников, и в целом охмурять — не мой бизнес. Не хочу, чтобы таких было побольше.
Кстати вполне соотносится с 60-ти дневной задержкой по оплате оказанных услуг. Нет результата — за что платить?
На самом деле конечный покупатель платит за все это.
Всегда. Всегда платить покупатель. За все.
Это будет или предоплата, куда фактически заложена эта 60-ти дневная оплата пропитания разработчика (та минимальная цена, за которую еще разработчик может работать). А вторая часть оплаты — это уже чистая премия разработчику за счет заказчика, то есть речь не идет ни о какой экономии и самых дешевых разработчиках — это всего лишь самообман. Самыми дешевыми получаются только те, кому платят ежедневно.
Либо это будет просто завышенная оплата в конце — куда заложены все риски. А это очень большая переплата.
P.S.:
Работаю на фриленсе лет 13 уже.
Все риски всегда на заказчике, даже если заказчик думает, что он самый умный и платит только по факту.
Иначе я давным давно двинул бы кони.
Скидку заказчик получает только по предоплате. При постоплате заказчик получает наценку. Всегда.
Это жизненно необходимо для закрытия себя от рисков.
Были бы все заказчики квалифицированы — закупались бы на фриланс биржах напрямую, а не через прокладки.
Отнюдь, и не суть в этом.
Иногда (часто) заказчика не нужны риски.
Заказчикам нужен комфорт.
И чем крупнее проект — тем больше риски с фриленсерами.
Если заказчик сам управляет этими рисками, то есть сам возится с фриленсерами, ежедневно их контролируя — то так жить можно.
Если заказчик сам не желает этого делать — он просто платит больше тому, кто берет риски на себя — в фирму-прослойку. И тогда с конечными разработчиками сюсюкаются уже фирмы-прослойки. И заслужено получают за это свои деньги.
И чем заказчик крупнее (богаче, жирнее) — тем он больше имеет возможностей на кого-то переложить свои головняки и сосредоточиться на главном.
Для мелкобизнесменов разумеется, крайне выгодным является самому стать квалифицированным — это позволяет существенно экономить.
Даже более того, даже самому выполнять какие-то части проекта — это действительно крайне эффективно для заказчиков без денег.
Вы полагаете, что самому стать квалифицированным — это существенная экономия? Нет, это как раз и есть тот самый самообман о дешевых разработчиках и экономии.
Если вы достаточно богаты, чтобы нанимать квалифицированных узкоспециализированных по ИТ менеджеров — смысла нет работать самому.
Но мы говорим о вполне конкретной ситуации — о позиции человека который выбирает разработчиков по минимальной цене, не составляет тех. задания и платить только по факту.
В его ситуации как раз если ты хорошо разбираешься в том, что заказываешь — ты можешь сэкономить, именно потому, что сможешь лучше контролировать процесс.
Но мы говорим о вполне конкретной ситуации — о позиции человека который выбирает разработчиков по минимальной цене, не составляет тех. задания и платить только по факту.
В его ситуации как раз если ты хорошо разбираешься в том, что заказываешь — ты можешь сэкономить, именно потому, что сможешь лучше контролировать процесс.
Если надо все-таки ехать, а не препираться.
То нужно брать минимальную задачу, просить чтоб разрабы составили ТЗ на первый мини-этап и платить за сделанный этап.
Дешево, быстро, квалификация большая не нужна, все едет.
Вот что мешает работать так?
То нужно брать минимальную задачу, просить чтоб разрабы составили ТЗ на первый мини-этап и платить за сделанный этап.
Дешево, быстро, квалификация большая не нужна, все едет.
Вот что мешает работать так?
Чтобы в чем то хорошо разбираться нужен опыт, а опыт это время, а время это опять же деньги. В чём здесь экономия? А ещё, как говорится, я не настолько богат, чтобы покупать дешевые вещи.
Чтобы в чем то хорошо разбираться нужен опыт, а опыт это время, а время это опять же деньги. В чём здесь экономия?
Если ваш опыт обошелся Вам дороже, чем потом применение вашего опыта на практике — какой вам смысл вообще работать? Это ж сплошные убытки.
Прошлый опыт — намного дешевле, чем тот профит, что мы с него потом получаем.
Ну во-первых, как тут многие сказали, обычно ТЗ, который приносит заказчик — это мусор, который в 90% выкидывается в помойку. Во-вторых, картина обычно следующая:
Заказчик: Вот вам ТЗ, делайте.
Исполнитель — Яволь!
Через какое-то время…
Исполнитель: сделали
Заказчик: Что это?
И: Ну как, по ТЗ.
Далее возможны варианты — мы не то просили (конечно, одно дело бумажка, другое дело реальный продукт). Или — вы с ума сошли? Уже год прошел — бизнес поменялся, нам теперь это вообще не надо.
Да, исполнитель получит деньги, заказчик будет недовольный, а продукт пойдет на полку…
PS Уже лет 15 лет работаю в основном на внутренних проектах, работал и в аутсорсе немного, но на внутренних проектах ТЗ не нужно. Напрасная трата времени и денег. Есть конкретный заказчик, есть исполнитель — все довольны, все ОК. И софт, которым пользуются.
Заказчик: Вот вам ТЗ, делайте.
Исполнитель — Яволь!
Через какое-то время…
Исполнитель: сделали
Заказчик: Что это?
И: Ну как, по ТЗ.
Далее возможны варианты — мы не то просили (конечно, одно дело бумажка, другое дело реальный продукт). Или — вы с ума сошли? Уже год прошел — бизнес поменялся, нам теперь это вообще не надо.
Да, исполнитель получит деньги, заказчик будет недовольный, а продукт пойдет на полку…
PS Уже лет 15 лет работаю в основном на внутренних проектах, работал и в аутсорсе немного, но на внутренних проектах ТЗ не нужно. Напрасная трата времени и денег. Есть конкретный заказчик, есть исполнитель — все довольны, все ОК. И софт, которым пользуются.
UFO just landed and posted this here
1. ТЗ это инструмент для налаживания взаимопонимания, идеально когда оно отвечает на вопрос:
— что надо сделать?
— на вопрос КАК надо сделать ТЗ отвечает не всегда, т.к. не всегда это понятно и есть много вариантов.
2. ТЗ должно быть понятно и заказчику и исполнителю
3. Читать должны заказчик и исполнитель.
— хорошо когда ТЗ из маленьких блоков, которые легко превращаются в задачи в таск-менеджере
— я люблю когда один блок — одна демонстрация, чем раньше начать демонстрацию готовых кусков по ТЗ заказчику — тем лучше, тем меньше переделок, тем меньше непонимания
4. Вместе! Работа совместная, иначе ад
5. Хорошо бы иметь опыт уже реализованных похожих проектов
6. Критерий качества: заказчик и исполнитель готовы расписаться, что понимают что нужно сделать
7. Я предпочитаю
— писать ТЗ на маленькие этапы, в них изменения либо некритичные, либо приводят к отмене всего этапа и пересмотру всего контракта
— я предпочитаю предложить доделать этап и к нему написать новое ТЗ на изменение
* иначе все вязнет
8. Аналитик — отвечает за выстраивание отношений с заказчиком и разработчиком. Он занимается челночной дипломатией, помогает достичь договоренностей. Чтобы с одной стороны заказчик получил именно то, о чем мечтал, с другой стороны чтобы это что-то было понятным и реализуемым.
Аналитик помогает заказчику сформулировать задачи, а разработчикам сформулировать ограничения.
9. ТЗ помогает помнить договоренности и по возможности не уходить от них далеко. Судебный процесс — дело на годы, если взаимонепонимание зашло так далеко, то в суде ТЗ не особо кого спасет.
10. ТЗ — это план для будущего user manual, но не его содержание.
Резюмируя:
ТЗ отвечает на вопрос: «Что нужно сделать?»
Проектная документация отвечает на вопрос: «Как это сделать?»
Мануал отвечает на вопрос: «Как это эксплуатировать?»
Аналитик помогает сформулировать задачи с одной стороны и ограничения по реализуемости с другой стороны
— что надо сделать?
— на вопрос КАК надо сделать ТЗ отвечает не всегда, т.к. не всегда это понятно и есть много вариантов.
2. ТЗ должно быть понятно и заказчику и исполнителю
3. Читать должны заказчик и исполнитель.
— хорошо когда ТЗ из маленьких блоков, которые легко превращаются в задачи в таск-менеджере
— я люблю когда один блок — одна демонстрация, чем раньше начать демонстрацию готовых кусков по ТЗ заказчику — тем лучше, тем меньше переделок, тем меньше непонимания
4. Вместе! Работа совместная, иначе ад
5. Хорошо бы иметь опыт уже реализованных похожих проектов
6. Критерий качества: заказчик и исполнитель готовы расписаться, что понимают что нужно сделать
7. Я предпочитаю
— писать ТЗ на маленькие этапы, в них изменения либо некритичные, либо приводят к отмене всего этапа и пересмотру всего контракта
— я предпочитаю предложить доделать этап и к нему написать новое ТЗ на изменение
* иначе все вязнет
8. Аналитик — отвечает за выстраивание отношений с заказчиком и разработчиком. Он занимается челночной дипломатией, помогает достичь договоренностей. Чтобы с одной стороны заказчик получил именно то, о чем мечтал, с другой стороны чтобы это что-то было понятным и реализуемым.
Аналитик помогает заказчику сформулировать задачи, а разработчикам сформулировать ограничения.
9. ТЗ помогает помнить договоренности и по возможности не уходить от них далеко. Судебный процесс — дело на годы, если взаимонепонимание зашло так далеко, то в суде ТЗ не особо кого спасет.
10. ТЗ — это план для будущего user manual, но не его содержание.
Резюмируя:
ТЗ отвечает на вопрос: «Что нужно сделать?»
Проектная документация отвечает на вопрос: «Как это сделать?»
Мануал отвечает на вопрос: «Как это эксплуатировать?»
Аналитик помогает сформулировать задачи с одной стороны и ограничения по реализуемости с другой стороны
Что есть ТЗ? Одна задача «Поменять надпись на кнопке» — это ТЗ?
Есть формализованное представление ТЗ. есть рекомендации к формулировке:
- Атомарность требования.
- Система должна формировать отчет Х. форма отчета см приложение № (правильно)
- Система должна формировать отчет Y. форма отчета см приложение № (правильно)
- Система должна формировать отчеты. (не правильно)
- Проверямость требования.
- Система должна обеспечить время формирования отчета не более чем за ### при нагрузке в ### запросов. (это правильно)
- Система сохранять отчет. (это НЕ правильно)
- Непротиворечивость требований.
- Система должна работать на микропроцессорах с системой комманд MIPS под операционной системой Windows 10 Pro
Кто должен писать ТЗ, заказчик или исполнитель со слов заказчика?
Это СОГЛАШЕНИЕ двух сторон, которе после закрепляется юридически. значит требуется участие двух сторон.
Какие возможны критерии качества ТЗ, чтобы определить хорошее оно или плохое? И насколько эти критерии разнятся между заказчиком и исполнителем? Можно ли одним ТЗ удовлетворить обе стороны?
Есть формализованные трбования:
- Юридические
- технологические. см страндарты ISO
Кому предназначается ТЗ? Кто те люди (роли), кто должны его читать?
Читают все участники проекта — это ПУБЛИЧНЫЙ документ :)
Со стороны Подрядчика — согласно требуемых ролей в проекте (Hr, менеджеры, юристы, UI/UX спецы, архитекторы, разработчики для связанных задач, QA, развертывание, сопровождение ...)
Каков процесс изменения ТЗ? Ведь, если мы начали работу по уже написанному ТЗ, то любое его изменение вероятнее всего повлияет на оценку проекта. Почти всегда отклонение оценки будет не в пользу исполнителя (нужно больше усилий, времени, денег).
Стандартная процедура Change Management. Так и есть. каскадные изменения.
Не является ли ТЗ (как увесистый документ), чаще всего лишь, не совсем удачным способом описания юридической ответственности сторон? И по сути, обеспечивает процесс продажи и заключения сделки, а не исполнения проекта?
Нет. Не является. Если подрядчик идиот, то ему просто выстявят неустойку за неисполнение проекта, плюс упущенную прибыль :) Про репутацию лучше и не заикаться :)
Почему считается, что БИЗНЕС-аналитики должны писать ТЕХНИЧЕСКОЕ задание? Каков должен быть вклад бизнес-аналитика в ТЗ?
Это не являтся обязательным. Но если специфическая область (банки, таможня, здравохранение и т.д.) то владение терминологией значительно упрощает и ускоряет написание ТЗ, заодно устраняет явные косяки при его написании. Если стороны не владеют в полной мере нюансами предметной области, его могут отдать на резензирование третьей стороне на условиях NDA.
Может ли документация (user manual) на готовый проект, считаться его ТЗ? Насколько тесно связаны документация и ТЗ
Может ли йогурт считаться молоком? Мануал — это результат исполения ТЗ. При корректном процессе исполнения, ТЗ будет являться «оглавлением» мануала :)
Попробуем.
1. Что есть ТЗ? Одна задача «Поменять надпись на кнопке» — это ТЗ?
Задание что должно быть изготовлено — все чертежи, схемы компонентов, измеряемые параметры которые позволят «рабочему продукту» воплощаемому в веществе «выйти за ворота цеха» через кпп.
ТО есть да — даже на гайку есть тз, на изготовление зубочистки есть тз, на внесение изменений есть тз — задание что нужно сделать в детальной проектировке.
2. Насколько техническим или бизнес-ориентированным должно быть ТЗ?
Техническое задание — это к примеру тот документ, который регламентирует как именно на итальянском станке вы выплавите себе упаковку для молока. Для китайского станка тз будет другим, потому что оно выстраивается из ТТХ возможностей производственной линии. Для многих это в жизни разработки оказывается сюрпирзом. ТЗ это внутренний уведомительный документ для производства. Клиент его может видеть может и не видеть — дело ваше.
Бизнес-ориинетированными являются другие документы — документированная концепция (то что подразумевается сделать), бизнес-область применения решения, действующие лица, цонтекст, ожидания от поведения системы — сюда я обычно пачкой складываю все макеты проротипы и эскизы от клиента, которые идут «в основание» скетчей, потом дизайна и рабочих чертежей состояний компонентов, ну и после всего этого концепта, на основании этих писюлек пишутся «трбебования к стисеме» — что дложно быть реализовано, с точки зрения «черного ящика» (мы хотим тыкнуть сюда пальцем и откуда-то отсюда вылетит птичка, мы не знаем как это делается внутри — как она там запускается, стартует и тд). Ну и на основании каждого требования пишется архитектурное решение с покзыванием клиенту. Если не учли какие-либо его потребности и пожелания (а надо было) на первом этапе и этот этпа прошел, становится возможным предложить клиенту выполнить всю работу по цепочке с самого начала когда он захочет влиять на архитектуру (те самые «подвинуть или подкрасить»).
Концепиция (инбокс и упорядочивание всего что прилетело, обсуждено на встрече, под подпись) -> на основании концепции делаются требования — > на основании требований пишется архитекутра.
Вот это все и обычно размазывает кто как умеет называя это ТЗ. Три разных документа, три разных специализации (наборы действий для выявления данных и их документирования) — от секретаря и менеджера до аналитика и инженера-архитектора.
3. Кому предназначается ТЗ? Кто те люди (роли), кто должны его читать?
Все участники проекта. Это некий baseline где хрантится весь проект от замысла до ввода в эксплуатацию.
4. Кто должен писать ТЗ, заказчик или исполнитель со слов заказчика?
Задавать вопросы и обработать все возможные входящие (ссылки на сайты, прототипы, криворукие документы ворд / экселя, какие-то мега идеи и «хорошо проработанные задания») должен менеджер и сделать из этого концепцию (опись бреда) и получить роспись, Аналитик должен бред разложить по полочкам, выявить недостающие элементы вопросаами, задокументировать требования. Подписать. Архитекор должен разложить ключевые экраны и элементы в скетчах. Подписать — дальше производство дело техники.
5. Какими компетенциями должен обладать человек, пишущий ТЗ?
Коммуникабельность, стрессоустойчивость, шлем — задавая вопросы, кажущиеся «очевидными» или повторяющимися любой собеседуемый человек начинает бесится как непонятно кто и непонятно почему — это факт, работу надо довести до конца и не пострадать — я часто работю со спорсменами высокого уровня «добился сам» и желающими войти в эти ваши технологии. Бывает очень часто интересное после третьего вглубь вопроса «зачем».
6. Какие возможны критерии качества ТЗ, чтобы определить хорошее оно или плохое? И насколько эти критерии разнятся между заказчиком и исполнителем? Можно ли одним ТЗ удовлетворить обе стороны?
Критерии качества есть, растут из исошек по системной инженерии — качественным считается продукт или система, соответсвующая заданным качествам (в тз и этих документах критерии качества это заполненность всех важных структур — стейкхолдеры, интересы, цели, задачи, требования, сиуациии, ожидания… и связей между ними. Много их есть они все ( старый пример http://files.pavlyut.com/mindactions_v2.2.3.png)
7. Каков процесс изменения ТЗ? Ведь, если мы начали работу по уже написанному ТЗ, то любое его изменение вероятнее всего повлияет на оценку проекта. Почти всегда отклонение оценки будет не в пользу исполнителя (нужно больше усилий, времени, денег).
Два вопроса тут. Первый — процесс изменения документируется и отражается от начала до конца как обычно, тз как документ это место постоянных иземенений — важная особенность что всегда есть «последняя согласованная версия» от которой идет коммуникация.
Второй это то что вы вкладываете в варианты «обилечивания» — я например ушел в итоге от часов и у меня есть конкретная смета на проект которую клиент все время подписыает. Компоненты сметы изначально увтерждаются заранее и клиент знает принцип ценообразования. (это полностью кастомная разработка всегда, хотя я могу это навесить на любые хери типа битрииксов или чего угодно, есть четкие замеры на выходе сколько человек получил «накоденного» и мереется это не по коду а по юзаджу).
Поэтому должна быть четкая привязка к ценообразованию на что и как влияют изменения — иначе жопа кеды. Система вещица динамичная и существует только в глазах смотрящего.
8. Почему считается, что БИЗНЕС-аналитики должны писать ТЕХНИЧЕСКОЕ задание? Каков должен быть вклад бизнес-аналитика в ТЗ?
Бизнес аналитик «анализирует» все входящие материалы, как правило он совмещается на первой встрече с менеджером помогая сразу задать нужные вопросы, но при наличии принятой формы анкетирования на встрече бизнес аналитик как раз не нужен чтобы не открывать ящик пандоры фантазий клиента. Тут практикуется психология, расслабление клиента и уверения его в прекрасном будущем. Это аккаунтинг. Технически у меня девченка справляется уже с этим хорошо (и это лучше — клиенты любят зачем-то быть мягкими идиотами при девушках, вне зависимости от возраста/статуса/должностей).
То есть аналитики анализирует — всю входящую информаци соединяет, находит связи, выстраивает из хаоса порядок и передает дальше. Тут практики и методы анализа и категоризации, систематизации.
Архитектор проектирует — у него должны быть навыки и опыт проекирования и запуска в эксплуатацию спроектированного — у него тут свои практики и методы — ux / ui вот это все тут.
9. Не является ли ТЗ (как увесистый документ), чаще всего лишь, не совсем удачным способом описания юридической ответственности сторон? И по сути, обеспечивает процесс продажи и заключения сделки, а не исполнения проекта?
Сложно утвреждать про «чаще всего» потому как чаще всего за все время работы я вижу настолько дичайшую сложность описать систему, и ее поведение, что в итоге понял что это проблема не описания а «воображения». Я как-то злился на клиента думал что он мне выносит мозги просто, когда я ему дал рабочий прототип и раскадровку с описью, ну тут вообще не возможно представить как-то по-иному, и вот он со всей серъезностью не понимал «как это будет работать», говорит ты собери и я пойму, так ничего не понятно. Это был не первый случай и я честно делаю вывод что он «в голове собрать и повертеть» даже элементарно не может не получается у человека — и это не его проблемы а мои, и я решли этот вопрос — покликал под видео прототип.
Поэтому что туда пишут часто это такой бред сивой кобыли что да, там кто-то запишет про показатели яндекса, кто-то укажет оттенок цвета, кто-то укажет пеню оплаты за услуги, кто-то напишет что должно быть 2 человека в группе разработке (схерали не скажет конечно, не приведет раскладку и обоснование с указанием методов и аргументации зачем и как это принесет какую именно пользу, и с хера ли вообще он полез в тех часть и тд).
Но про процесс продажи это правда — как указал ранее, тз как раз «замеряет» что пошло в «цех» — это это надо обилечивать обязательно. Пишите проессы.
10. Может ли документация (user manual) на готовый проект, считаться его ТЗ? Насколько тесно связаны документация и ТЗ?
Не может — это пост документ который тоже пишется по договоренностям, с учетом культурно-обусловленной позиции действующих в системе стейкхолдеров (персонажей).
Надеюсь помог чуточку раскрыть тему.
1. Что есть ТЗ? Одна задача «Поменять надпись на кнопке» — это ТЗ?
Задание что должно быть изготовлено — все чертежи, схемы компонентов, измеряемые параметры которые позволят «рабочему продукту» воплощаемому в веществе «выйти за ворота цеха» через кпп.
ТО есть да — даже на гайку есть тз, на изготовление зубочистки есть тз, на внесение изменений есть тз — задание что нужно сделать в детальной проектировке.
2. Насколько техническим или бизнес-ориентированным должно быть ТЗ?
Техническое задание — это к примеру тот документ, который регламентирует как именно на итальянском станке вы выплавите себе упаковку для молока. Для китайского станка тз будет другим, потому что оно выстраивается из ТТХ возможностей производственной линии. Для многих это в жизни разработки оказывается сюрпирзом. ТЗ это внутренний уведомительный документ для производства. Клиент его может видеть может и не видеть — дело ваше.
Бизнес-ориинетированными являются другие документы — документированная концепция (то что подразумевается сделать), бизнес-область применения решения, действующие лица, цонтекст, ожидания от поведения системы — сюда я обычно пачкой складываю все макеты проротипы и эскизы от клиента, которые идут «в основание» скетчей, потом дизайна и рабочих чертежей состояний компонентов, ну и после всего этого концепта, на основании этих писюлек пишутся «трбебования к стисеме» — что дложно быть реализовано, с точки зрения «черного ящика» (мы хотим тыкнуть сюда пальцем и откуда-то отсюда вылетит птичка, мы не знаем как это делается внутри — как она там запускается, стартует и тд). Ну и на основании каждого требования пишется архитектурное решение с покзыванием клиенту. Если не учли какие-либо его потребности и пожелания (а надо было) на первом этапе и этот этпа прошел, становится возможным предложить клиенту выполнить всю работу по цепочке с самого начала когда он захочет влиять на архитектуру (те самые «подвинуть или подкрасить»).
Концепиция (инбокс и упорядочивание всего что прилетело, обсуждено на встрече, под подпись) -> на основании концепции делаются требования — > на основании требований пишется архитекутра.
Вот это все и обычно размазывает кто как умеет называя это ТЗ. Три разных документа, три разных специализации (наборы действий для выявления данных и их документирования) — от секретаря и менеджера до аналитика и инженера-архитектора.
3. Кому предназначается ТЗ? Кто те люди (роли), кто должны его читать?
Все участники проекта. Это некий baseline где хрантится весь проект от замысла до ввода в эксплуатацию.
4. Кто должен писать ТЗ, заказчик или исполнитель со слов заказчика?
Задавать вопросы и обработать все возможные входящие (ссылки на сайты, прототипы, криворукие документы ворд / экселя, какие-то мега идеи и «хорошо проработанные задания») должен менеджер и сделать из этого концепцию (опись бреда) и получить роспись, Аналитик должен бред разложить по полочкам, выявить недостающие элементы вопросаами, задокументировать требования. Подписать. Архитекор должен разложить ключевые экраны и элементы в скетчах. Подписать — дальше производство дело техники.
5. Какими компетенциями должен обладать человек, пишущий ТЗ?
Коммуникабельность, стрессоустойчивость, шлем — задавая вопросы, кажущиеся «очевидными» или повторяющимися любой собеседуемый человек начинает бесится как непонятно кто и непонятно почему — это факт, работу надо довести до конца и не пострадать — я часто работю со спорсменами высокого уровня «добился сам» и желающими войти в эти ваши технологии. Бывает очень часто интересное после третьего вглубь вопроса «зачем».
6. Какие возможны критерии качества ТЗ, чтобы определить хорошее оно или плохое? И насколько эти критерии разнятся между заказчиком и исполнителем? Можно ли одним ТЗ удовлетворить обе стороны?
Критерии качества есть, растут из исошек по системной инженерии — качественным считается продукт или система, соответсвующая заданным качествам (в тз и этих документах критерии качества это заполненность всех важных структур — стейкхолдеры, интересы, цели, задачи, требования, сиуациии, ожидания… и связей между ними. Много их есть они все ( старый пример http://files.pavlyut.com/mindactions_v2.2.3.png)
7. Каков процесс изменения ТЗ? Ведь, если мы начали работу по уже написанному ТЗ, то любое его изменение вероятнее всего повлияет на оценку проекта. Почти всегда отклонение оценки будет не в пользу исполнителя (нужно больше усилий, времени, денег).
Два вопроса тут. Первый — процесс изменения документируется и отражается от начала до конца как обычно, тз как документ это место постоянных иземенений — важная особенность что всегда есть «последняя согласованная версия» от которой идет коммуникация.
Второй это то что вы вкладываете в варианты «обилечивания» — я например ушел в итоге от часов и у меня есть конкретная смета на проект которую клиент все время подписыает. Компоненты сметы изначально увтерждаются заранее и клиент знает принцип ценообразования. (это полностью кастомная разработка всегда, хотя я могу это навесить на любые хери типа битрииксов или чего угодно, есть четкие замеры на выходе сколько человек получил «накоденного» и мереется это не по коду а по юзаджу).
Поэтому должна быть четкая привязка к ценообразованию на что и как влияют изменения — иначе жопа кеды. Система вещица динамичная и существует только в глазах смотрящего.
8. Почему считается, что БИЗНЕС-аналитики должны писать ТЕХНИЧЕСКОЕ задание? Каков должен быть вклад бизнес-аналитика в ТЗ?
Бизнес аналитик «анализирует» все входящие материалы, как правило он совмещается на первой встрече с менеджером помогая сразу задать нужные вопросы, но при наличии принятой формы анкетирования на встрече бизнес аналитик как раз не нужен чтобы не открывать ящик пандоры фантазий клиента. Тут практикуется психология, расслабление клиента и уверения его в прекрасном будущем. Это аккаунтинг. Технически у меня девченка справляется уже с этим хорошо (и это лучше — клиенты любят зачем-то быть мягкими идиотами при девушках, вне зависимости от возраста/статуса/должностей).
То есть аналитики анализирует — всю входящую информаци соединяет, находит связи, выстраивает из хаоса порядок и передает дальше. Тут практики и методы анализа и категоризации, систематизации.
Архитектор проектирует — у него должны быть навыки и опыт проекирования и запуска в эксплуатацию спроектированного — у него тут свои практики и методы — ux / ui вот это все тут.
9. Не является ли ТЗ (как увесистый документ), чаще всего лишь, не совсем удачным способом описания юридической ответственности сторон? И по сути, обеспечивает процесс продажи и заключения сделки, а не исполнения проекта?
Сложно утвреждать про «чаще всего» потому как чаще всего за все время работы я вижу настолько дичайшую сложность описать систему, и ее поведение, что в итоге понял что это проблема не описания а «воображения». Я как-то злился на клиента думал что он мне выносит мозги просто, когда я ему дал рабочий прототип и раскадровку с описью, ну тут вообще не возможно представить как-то по-иному, и вот он со всей серъезностью не понимал «как это будет работать», говорит ты собери и я пойму, так ничего не понятно. Это был не первый случай и я честно делаю вывод что он «в голове собрать и повертеть» даже элементарно не может не получается у человека — и это не его проблемы а мои, и я решли этот вопрос — покликал под видео прототип.
Поэтому что туда пишут часто это такой бред сивой кобыли что да, там кто-то запишет про показатели яндекса, кто-то укажет оттенок цвета, кто-то укажет пеню оплаты за услуги, кто-то напишет что должно быть 2 человека в группе разработке (схерали не скажет конечно, не приведет раскладку и обоснование с указанием методов и аргументации зачем и как это принесет какую именно пользу, и с хера ли вообще он полез в тех часть и тд).
Но про процесс продажи это правда — как указал ранее, тз как раз «замеряет» что пошло в «цех» — это это надо обилечивать обязательно. Пишите проессы.
10. Может ли документация (user manual) на готовый проект, считаться его ТЗ? Насколько тесно связаны документация и ТЗ?
Не может — это пост документ который тоже пишется по договоренностям, с учетом культурно-обусловленной позиции действующих в системе стейкхолдеров (персонажей).
Надеюсь помог чуточку раскрыть тему.
В нашей компании, также практикуется (я даже скажу: не редко) работа без ТЗ, основная версия (процентов 90 работы без ТЗ) «для себя». За частую сторонний от IT отдел: менеджеры продаж, руководство, маркетологи, хотят получить некую мини программу (Конечно, — это они считают, что она мини), которая облегчит/улучшит выполняемую работу.
И тут, как говорится, начинается «мясо». ТЗ, писать не у кого нет времени, «Мы же делаем для себя, мы единый организм части которого работают в синергии, зачем же писать ТЗ», говорят они нам. В итоге: задача поставлена, найден этот «герой»-исполнитель, и уже тут запахло жареным:
«А что же делать?!», спрашивает «герой.
»Ну как, ты же сам писал этот сайт/виджет/ПО, тут же все понятно, что нужно доработать!!!", возмущенно отвечают ему…
И наш «герой» принимается за работу. Проходит пару дней, в которые естественно были ежедневные встречи с менеджером, вся программа была выполнена, задача выполнена. Менеджер и «герой», радостные, передали на тесты, получили положительные результаты, и пошли сдавать работу.
И тут происходят невероятные казусы, наш «герой» то оказывается «шут», а менеджер вообще куда смотрел?! Что вообще происходит?! Как такое допустимо?! Быстро уберите от нас это «УГ», возмущения можно описывать бесконечно в различных красках.
В итоге, бывали случаи, что доходило и до выговоров (ну это совсем крайние моменты). После кучи доработок и правок работу «героя-шута» принимают, в очередной раз оказавшись раздосадованными.
ИТОГ Сторонние от IT отделы, не в коей мере не хотят учиться на своих ошибках, считая, что это ошибки других-наши, они не каким образом не хотят проводить ретроспективы и учиться на прецедентах. Мы предпринимаем все меры, чтобы хоть как-то исправить ситуацию, пытаемся собирать требования, писать хоть какое-то ТЗ, но на нас продолжают смотреть с не пониманием — «время нужно тратить по другому», говорят они.
PS Не работайте без ТЗ!!!
И тут, как говорится, начинается «мясо». ТЗ, писать не у кого нет времени, «Мы же делаем для себя, мы единый организм части которого работают в синергии, зачем же писать ТЗ», говорят они нам. В итоге: задача поставлена, найден этот «герой»-исполнитель, и уже тут запахло жареным:
«А что же делать?!», спрашивает «герой.
»Ну как, ты же сам писал этот сайт/виджет/ПО, тут же все понятно, что нужно доработать!!!", возмущенно отвечают ему…
И наш «герой» принимается за работу. Проходит пару дней, в которые естественно были ежедневные встречи с менеджером, вся программа была выполнена, задача выполнена. Менеджер и «герой», радостные, передали на тесты, получили положительные результаты, и пошли сдавать работу.
И тут происходят невероятные казусы, наш «герой» то оказывается «шут», а менеджер вообще куда смотрел?! Что вообще происходит?! Как такое допустимо?! Быстро уберите от нас это «УГ», возмущения можно описывать бесконечно в различных красках.
В итоге, бывали случаи, что доходило и до выговоров (ну это совсем крайние моменты). После кучи доработок и правок работу «героя-шута» принимают, в очередной раз оказавшись раздосадованными.
ИТОГ Сторонние от IT отделы, не в коей мере не хотят учиться на своих ошибках, считая, что это ошибки других-наши, они не каким образом не хотят проводить ретроспективы и учиться на прецедентах. Мы предпринимаем все меры, чтобы хоть как-то исправить ситуацию, пытаемся собирать требования, писать хоть какое-то ТЗ, но на нас продолжают смотреть с не пониманием — «время нужно тратить по другому», говорят они.
PS Не работайте без ТЗ!!!
Кстати, я мельком прошелся по комментариям, не увидел замечательного момента (может плохо смотрел): пока пишешь ТЗ, т.е. разжевываешь задачу, в процессе видишь новые критерия, влияющие на решение. Новые комбинации значений этих критериев. Потребности во внесении изменений в заранее вроде бы складную модель решения и тд. Писать ТЗ в таком ключе абсолютно всегда полезно ;)
Вариант 1: работа заключается в поддержке и развитии проекта, вместо ТЗ мы работаем с так называемыми user story (устные описания того, какую проблему пользователя надо решить), которые обновляются раз в неделю. В результате обратная связь о проделанной работе прилетает довольно быстро как для разработчиков, так и для клиента, правки не приносят боль никому.
Вариант 2: делаю небольшие и средние подработки для других проектов коллег. В этом случае, во-первых, есть доверие, основанное на положительном опыте такой работы, а во-вторых, бюджеты и масштабы не такие, чтобы писать под них ТЗ, устного описания достаточно (возможно потому, что говорят какую проблему решить, а не что конкретно сделать).
Первое хорошо заходит, если работать полностью по agile, иметь ПО, который представляет заказчика и вносит грамотные коррективы на результат выполнения пользовательских хотелок, сейчас многие компании ориентированны на гибкую и итерационную разработку. Но мы столкнулись с проблемой: наши заказчики не готовы работать по agile, им подавай старый добрый «водопад». Но свои проекты мы пытаемся перевести на гибкую систему разработки.
Если у них есть бабло.
Открытый или хотя бы достаточно серьезный бюджет.
Иначе — никаких вам Agile
Открытый или хотя бы достаточно серьезный бюджет.
Иначе — никаких вам Agile
Работал три месяца над задачей взаимодействия с порталом госуслуг через СМЭВ. Формально было ТЗ с критериями приемки (4 сценария которые можно проверить). Реально в процессе работы ростелекомовцы выпустили 2 новые версии спецификации СМЭВ, и надо было их учитывать.
То есть все прелести внезапных хотелок были, только не со стороны заказчика, а со стороны третьих лиц.
Нормальное дело, часто сталкиваюсь с таким -)
Тогда почему этого варианта не оказалось в списке? Или вы считаете такое ТЗ-редирект полноценным ТЗ?
У меня несколько статей про ТЗ -)
Эта статья про БЕЗ ТЗ. У вас все-таки документация была, хоть она и менялась на ходу.
Похожую проблему я описывал в разделе «Коллективное творчество» в статье «ТЗ высокой четкости»
Эта статья про БЕЗ ТЗ. У вас все-таки документация была, хоть она и менялась на ходу.
Похожую проблему я описывал в разделе «Коллективное творчество» в статье «ТЗ высокой четкости»
Sign up to leave a comment.
Без ТЗ: как разработчики в такое ввязываются