Комментарии 134
Хотя был случай, когда в одном «ящике» людям предложили выкинуть из исходников ядра все неиспользуемые исходные коды драйверов. И весь отдел уволился (нереальная задача).
У меня был случай, когда мне за какие-то 50к предлагали отреверсить проткол обмена по CAN шине с сервером, с кучей датчиков, без документации и предоставления доступа к самой шине. При этом ещё и не факт что заплатят. Когда я намекнул, что это мягко скажем работа не на месяц и не за 50к, на меня очень сильно обиделись. Хотя изначально мне предлагалось всего лишь написать демон под железку за эту сумму.
Ну, а в целом, как по мне лучше чем в старом известном видео придумать нельзя.
В целом я давно вынашиваю план написать про переговоры в IT-проектах. Ну так чтобы с серьезной литературой, академические ученые (среди которых нобелевские лауреаты). Написать какие основные школы переговоров есть, какие плюсы минусы и т.п. -)
Задача научится понимать заказчика (самый тяжёлый случай, если он не инженер и даёт инженерную задачу) и исполнителя (инженера или программиста). В общем, переформулирую тезисно: неспециалист придумывает задачу и даёт специалисту, не представляя даже отдалённо проблем. Специалист должен не показать вида, что заказчик
Вот тут стоит искусство коммуникации. В ролике выше как раз показаны проблемы не работающего искусства коммуникации.
Запускаем разраба в комнату с заказчиком, и он должен:
— не выругаться
— не заржать
— угадать, что тот хотел
Если смог, то проходит в другую комнату, если заржал, ругается, время кончилось квест не пройден -)
Но почему-то им нужен тех.специалист, который не умеет «коммуникацию».
Т.е. там 3 (ТРИ) человека не нужны, т.к. они не делают свою работу, и их можно безболезненно уволить. :-)
Для одного параллельные — непременно непересекающиеся прямые, и перпендикулярность определена исключительно для прямых. Для другого — любые линии, которые всюду находятся на одном и том же расстоянии друг от друга («параллельные кривые»), а перпендикулярность определяется локально (в данной точке строим касательные к кривым и измеряем угол между ними, если 90° — кривые перпендикулярны).
Для одного прозрачный — это тот, который не видно, вообще не видно, а видно то, что находится за ним. Для другого прозрачный включает и «полупрозрачный» тоже.
Для одного котёнок — это объект трёхмерный, ну ладно, изображение может быть двумерным, но линия-то объект строго одномерный и не может быть в форме двумерного (про кривую Пеано он, предположим, не слышал). Для другого — линия — это как след от грифеля карандаша, вполне имеет осязаемую ширину, и можно сделать её любой формы, например, в форме котёнка.
И вывод: прежде, чем обсуждать, нужно договориться об определениях, и потом следовать им. Чтобы одни и те же слова понимать одинаково.
Вообще у этого «эксперта» какое-то ужасно узкое и закостенелое понимание мира. Дальше своих школьных знаний он ничего не приемлет. Наверное, на того, кто ему расскажет, будто можно определить операцию квадратного корня из отрицательных чисел, он тоже посмотрит как на идиота.
Не понимаю за что человеку столько минусов, хоть бы кто написал что не так.
Стараюсь отучаться.
Гораздо лучше вопрос: «Какие у вас ожидания», или «Допустим, все получится, опишите что тогда?»
Нужно по другому. Для чего вы это хотите? что вам это даст? Какая цель этого действа? Что в конце должно быть? и т.д.
Ответ должен быть не «я хочу котенка», а «я хочу продать это в майкрософт».
Смелость часто подразумевает низкий уровень осознанности.
Это означает, что вопрос: «Что хочешь, что даст, какая цель, что в конце» ставит их в тупик! Да-да!
А вот что они ждут, или как они видят успех — обычно могут рассказать -))))
Дичь это фильтр на видео по поиску лады баклажан за 2к рублей
Дичь — рекламные щиты в лифт за 5к рублей с полной разработкой сервера и т.д.
Дичь — сделать убийцу фейсбука
и т.д.
Что интересно, даже собственноручно его сиятельством подписанные бумажки не действуют! Ответ может быть такой, например: «Я не осознавал, что подписываю, вы просто воспользовались моим непониманием тонкостей и получили утверждение при помощи хитрости!»
боится, что завалит на первом же допросеПолагаю что если его возьмут на работу после такого, то слово сменит свою первую букву. Очень уж это пром. шпионажем со стороны заказчика отдаёт.
Писал несколько ТЗ по нему. Получилось очень даже ничего.
А то, что автором приводится в начале темы — это не ТЗ, это заявление о намерениях, не имеющие с ТЗ ничего общего.
У меня есть заказчики, которые кидают в меня ТЗ по ГОСТу, или детально документированным API на 200 страницах и просят разобраться и объяснить разрабам, а что делать собственно надо -)
Прошло более полугода и я до сих пор наблюдаю на известном сайте поиска работников вакансию сисадмина с глубоким знанием Asterisk за корок сопеек. А клиенты так и звонят то в call center, то на сотовый кладовщику, то на городской бухгалтеру…
может стоило после второго раза остановиться и накидать расчёты на салфетке?
По итогу, директор хочет возложить создание АТС с распределенной сетью магазинов и call-центром на сисадмина с з.п. 30 тыс :)
Начинать надо с изучения сегмента рынка на котором
собираешься работать. Сбор информации, анализ.
Идти на встречу с заказчиком желательно после
синтеза собственного видения проблемной области.
В идеале — прототипировать пару-тройку экранов, еще лучше
это сделать совместно с дизайнером, чтобы глаз радовало.
Имея на руках презентацию и прототип легче перевести разговор с заказчиком
в конструктивное русло. На самом деле, рынки уже сложились.
Обзоры есть в продаже. Нормативная база также. Часть инфы гуглится.
Нарабатывать базу прототипов можно и заранее, не дожидаясь
звонков от клиентов. Добавлю, что автору удалось в статье очень логично
и талантливо в рамках своей собственной уникальной системы понятий описать процесс коммуникации
с клиентом, но к техническому заданию, как к регламентному документу
это не имеет отношения. Скорее протоколы, спецификации, психологические заметки,
но не ТЗ.
Даже сервис сделал совсем недавно на эту тему (androrder.xyz/h4w), но судя по статистике создаваемых проектов пользователями — идея им не очень нравится и составление ТЗ останавливается на 3-4 строчке.
Часто рассказ о жизни заказчика (чем он живет, кем работает, какое образование, как ему пришла эта идея, откуда, что он ждет от этого проекта) помогает в составлении правильного ТЗ лучше чем наличие ясных целей и задач.
Ведь они могут быть ложными, а история жизни обычно не врет -)
Но вопрос один имеется: «ТЗ высокой четкости» для кого?
Я разработчик и бывало такое когда ТЗ утвердило руководство, акцептовал начальник отдела аналитики собрали все подписи с клиента, а потом удаленький разработчик задает маленький вопрос и все летит в там-тарары.
Когда клиент сам пытается родить именно решение — все упирается в его скилл. Как правило он никакой, оттуда и решения никакие (то розовую кнопку по центру экрана попросит, то еще что). Но это не отменяет наличия у него проблемы или потребности.
Если клиент пришел и говорит: «Хочу, что бы вы мне голову отрубили», то надо на автомате уточнить: «А исходя из чего Вы приняли такое решение? Какую жизненную задачу мы закроем? Какие еще решение рассматривали?» и т.д. т.п. Финансово частенько выгодно сказать: «Так точно! Будет сделано!», а потом на возражение клиента выдавать: «ВСЁ ПО ТЗ!». Но это не по «нашему» =)
Мне пока везет и клиенты с большим пониманием и доверием относятся к тому, что с них проблема/окружение/пожелания, а с меня поиск решения. Так не с первой встречи, но в процессе данный подход очевидно побеждает «Сделайте нам вот сюда вот именно вот так! Сколько стоит?» (если речь про долгосрочные отношения).
2. Иногда кажется, что проблема или желание яснее ясного, все по полочкам разложено и записано, а потом оказывается, что что-то упустил.
3. Часто в ходе разработки проблема или желание меняются до неузнаваемости, но не всегда заказчик это осознает. Ему кажется, что всегда он хотел именно этого, просто вы не поняли.
4. Изменения проблем и желаний могут быть по массе причин: рынок изменился, осознание изменилось, компания изменилась, мода изменилось.
Так что вам ооочень сильно везет -)))) Очень!
2. В любых договоренностях так может быть, очевидно.
3 и 4. А никто и не говорит что требования в камне. Они живые. Один разок я полгода писал ТЗ для лаборатории, а как подписали все шишки, смена законодательства и ТЗ в утиль. Я не расстроился ;)
Везет мне как всем, вопрос в постановке задачи/роли аналитика ;)
Бизнес прекрасно понимает, где у него жмет. Иначе бы не началось телодвижение.
Это выдает в вас сторонника теории рационального поведения экономических субьектов.
Есть немало современных экономистов, в том числе нобелевские лауреаты, которые убедительно доказываеют иррациональность поведения экономических субьектов. На вскидку можно почитать: Роба Шиллера, Джозефа Стиглица, Дэна Канемана, Джо Аркелофа.
Короче, телодвижение может начаться не из-за прекрасного понимания. А просто вот так начаться иррациональненько -)
Это выдает в вас сторонника теории рационального поведения экономических субьектов.
Нет не выдает ^^ Условно половину обращений я закрываю, мол «нет проблем», «переложить на других», «в данных условиях/формулировках/требованиях не решаются», «решаются штатными средствами», «решаются организационно/юридически/другое».
Для меня обращение бизнеса — это входящая задача. Решением задачи может быть в итоге ТЗ. Именно может быть, а не обязано.
«Бизнес» это не абстрактный конь в вакууме — это немножко другие, но все же люди обреченные доказывать свои высокие зарплаты своей часто сомнительной нужностью.
Инициатива проявлена? Суета создана? Что там технари что-то нарисовать не могут? А почему? Вот оно как… Ну не могут так не могут… ;)
Через так, получают дополнительную информацию, которую добывать сложно/долго/нудно/скучно/лень… И, на новый круг!
Для людей, которые любят и делают дело, бессмысленные совещания — помеха, для такого «бизнеса» — хлеб насущный.
2. «Коммуникация важнее документации» — это факт.
Интересная мысль. Выстраданная или преобретенная? На переговорах попросил бы определить «рациональность» с Вашей кочки зрения. :)
>На вскидку можно почитать: Роба Шиллера, Джозефа Стиглица, Дэна Канемана, Джо Аркелофа.
Можно поконкретнее — две три книги из серии 'mast have'? С ответом не тороплю.
По нобелевским лауреатам последних лет:
1. Шиллер «Иррациональный оптимизм» — там как инвесторы принимают решения
2. Стиглиц «Крутое пике» — о последствиях веры в «рациональность» рынков
3. Кругман «Выход из кризиса есть» — о том что можно сделать для экономики, поняв что экономические субъекты иррациональны
4. Шиллер и Аркелов «Spiritus Animalis» — как иррациональность правит экономикой
5. Канеман «Принятие решений в условиях неопределенности» — о том, как люди ошибаются в прогнозах и почему.
6. Канеман «Думай медленно, решай быстро» — название на русском абсолютно неправильное, но книга в продолжение темы принятия решений
И если хватит сил
Дэн Ариэли, думаю он тоже получит премию лет через 10:
1. Предсказуемая иррациональность
2. Позитивная иррациональность
3. Вся правда о неправде
Иногда формулирую их на 2-ом, 3-ем этапе.
Однако тестовый контент может все в корне поменять!
Бывают уникальные заказчики, которые сразу в состоянии увидеть цели и задачи.
Они на то и уникальны, что встречаются редко.
Поэтому на практике цели и задачи формулируются в процессе, а не в начале.
Однако разработчик их видит в самом начале обычно -)
При этом не будем забывать про классический этап «исследование предметной области».
Как-то все его опускают и считают бесплатным. Типа исследование предметной области и погружение в проблематику для джуниоров, а мы то профессионалы!
В 1998 меня учили в институте исследовать предметную область.
В 2008 мне казалось, что я сразу могу круто сформулировать цели и задачи для чего угодно.
А сейчас в 2017 я понимаю, что идти по ложному направлению совершенно нормально, главное не заходить далеко и двигаться маленькими шагами.
Обычно происходит так.
Есть проект. В начале «исследуют предметную область», «составляют требования» и т.д.
И типа пока код как-бы писать не надо, т.к. «мы исследуем».
Потом когда уже таки да все исследовали/изучили начинаю/ем писать код.
И тут ВНЕЗАПНО выясняется, все что исследовали/изучили ~80% можно просто выкинуть.
Т.к. увидев работающий прототип заказчик говорит, что здесь он думал другое, тут понял вот так.
А это вообще сделано не правильно, т.к. вы сделали как правильно (как написано в нормативных документах), а нам надо, как нужно (как мы в действительности работаем)
И происходит интерактивный процесс.
Прототип-> Уточнение->Прототип.
И так пока не закончатся деньги.
И это бы ничего, но обычно от 3 до 6 месяцев, как раз уходит на «исследования».
А потом за 3-4 месяца нужно сделать продукт.
Поэтому я за Agile. Т.е. заказчик должен как можно раньше увидеть прототип, чтобы он мог на что-то опереться и высказать, свое «фи».
В целом стараюсь договориться на стартовый этап недели на две как раз, чтобы увидеть прототип как можно скорее.
— по ТЗ работаю
— по Agile работаю
Разница стирается, если ТЗ маленькое и уменьшается в мини-спринт.
При этом все-таки вы поднимаете вопрос прогнозирования.
Допустим все по Agile, двигаемся мини-задачами, которые сразу подходят для внедрения.
Однако внедрение на стороне клиента не происходит с той скоростью, которую вы ожидали.
Сотрудники раскачиваются медленно.
И когда через 3-6 месяцев часть народа удается на систему пересадить, выясняется что был изначально выбран ложный путь. Причем понимание этого нарастает лавинообразно. Вот не было его и вдруг появилось, как мода или как кризис среднего возраста-)
Я разрабатываю аппаратно-программные платформы для управления силовой электроникой. В последнее время полюбил Jira, как средство для управления требованиями.
Т.е. каждое требование — это Issue. В описание обязательно должна быть прописана причина возникновения требования. Далее комментами выясняется и дополняется между всеми командами. В конце идет workflow по формальному review и approval.
Медленно, но верно. На основании требований создаются user stories и задания — каждое требование должно приводить к одному или более заданиям и каждое задание должно закрывать как минимум одно или несколько требований. Так появляется полная traceability от требований до svn.
А что заказчик по жире говорит?
По жире ничего, так как основная нагрузка на мне — как менеджере управления требованиями — правильно сформулировать, разбить одно большое требование на несколько мелких, связать вместе, направить нужному спецу для комментов и т.д.
Как правило со стороны заказчика сидят несколько специалистов, которые только комментируют и утверждают требования. Поэтому нагрузка на каждого не такая большая и им собственно пофиг — то ли жира это, или что-то другое.
Самый неприятный вопрос к заказчику, как уже обсуждали выше — это "Зачем?". Вытягивать приходится за уши, граблями. И тогда вылазят такие интересные вещи, что жира постепенно превращается в кладезь мудрости.
От меня заказчикам так легко не уйти. Мы как бы под одной крышей. По теории каждое требование — это желание, потребность. А потребность возникает по какой-то причине. Если причины нет, то и потребность не возникнет. Следовательно ответ на вопрос "Зачем" позволяет лучше определить причины возникновения требования и в конце концов выяснить, насколько оно важно заказчику.
Часто в процессе выяснения "зачем" требование меняется до неузнаваемости.
Например в процессе обсуждения одного из самого простых требований: "Устройство должно работать в диапазоне температур от -25°C до +55°C" выяснилось, что:
- устройство будет эксплуатроваться только в кондиционированных помещениях, но
- по всему миру, а индусы — теплолюбивые люди и при 20° им холодно, поэтому они отключают кондиционер
- часто это требование стоит в клиентских спецификациях, когда система с устройством сдается под ключ
- другие аналогичные устройства от конкурентов имеют такие же рейтинги — чего наше должно быть хуже?
- +55°C удовлетворит 80% текущих клиентов, оставшиеся 20% требуют +65°.
- есть стандарт МЭК, по которому -25°C...+55°C — это стандартный ряд, а допустим -25°C...+60°C — это уже не рекомендуемый диапазон.
И так далее. В результате это очень сильно влияет на выбор решения, даже если требование в результате не изменяется.
Из недавнего прошлого. Средней величины компания, хочет новый лендинг. Пытаюсь набросать бриф. В каждой итерации постоянно появляются всё новые и новые крупные фичи. При этом всё время звучит один и тот же вопрос «а сколько всё это будет стоить». На что я постоянно отвечаю «давайте сперва определимся, что вы хотите в виде ТЗ».
На 3-4 итерации меня спросили «а у вас есть рыба ТЗ или может откуда-то это можно скачать?», на что я сидел с выражением «рука-лицо» и ответил сухо «такого не может быть в принципе» и, понимая неизбежность нечеловеческих затрат времени на детализацию ТЗ, посоветовал им нанять аналитика, если у них нет квалифицированного человека, готового ответственно отнестись к проектированию.
Тем не менее, через месяц мне прислали содранное откуда-то замшелое ТЗ со своими правками, в которых всё равно ничего не было написано про те фичи, о которых мне рассказывали ранее. Зато было пожелание поддерживать IE 5.0, Firefox 1.0, Chrome 5.0 и какой-то набор диких разрешений мобильных устройств и адаптивную верстку, при этом имея только один макет дизайна под 1280px.
На это мне ничего не оставалось сделать, как назвать с потолка сумму денег, окупившую бы весь гемор по этому ТЗ и серию вопросов «я правильно понял, что вы хотите то-то и то-то?». Там ошалели от стоимости. И конечно же оказалось, что мало чего нужно было, но дополнительной инфы так и не предоставили.
Как итог, я написал от всего сердца, что далее есть только одна возможность общения со мной на тему ТЗ — платить деньги за его составление. Либо не общаться со мной, а заплатить их аналитику, как делают все нормальные люди. В противном случае не смогу считать себя профессионалом, за результат и претензии не отвечаю, но деньги возьму вперед. Больше ответов пока не последовало.
Ах да. Вся это котовасия длилась полгода.
Но это вы еще не стартанули. У меня есть кейсы, где пол года согласовывали ТЗ и стартанули.
Вот тогда начинается самая мякатка -)
Больше всего умилило во всём этом не столько отсутствие понимания того, что хотят, сколько ощущение, что никому на самом деле этот проект не нужен, если учесть постоянные попытки спихнуть на меня написание ТЗ и отстраненность от этого процесса.
Если заказчик просит не ТЗ, а смету, то ему и нужно предоставить смету.
Это такая табличка с укрупнёнными фичами. Такая-то фича будет стоить столько-то и займёт столько-то времени, а следующая — столько-то и столько-то. С пояснением «в стандартной комплектации».
Дальше, если фича реально нужна, начинается обсуждение «стандартной комплектации». Это уже подфичи.
Ну я понимаю, что если вы конкретно ту или иную фичу никогда не делали, то и оценить её сходу, а тем более аргументированно перечислить её «стандартную комплектацию», достаточно сложно. А если вообще не представляете, как это сделать — невозможно. Ну тут извините, аналитика кормит опыт, которого вам не хватило.
Возникало ощущение, что заказчик как попугайчик выучил какие-то умные слова, но что это такое не понимает и хотел, чтобы я сам всё додумал)
Теперь он придирается к каждому пункту сметы: «а я не понимаю, почему эта фича займет у вас 6 часов, да это же 1,5 минуты»! -)))
Вот мы и думаем теперь, какие трудозатраты потребуются, чтобы с этим заказчиком спорить за каждый час в смете?
В целом отказ от ТЗ — уже симптом, который заставляет задуматься: а оно вам надо?
Читал статью, а в голове упорно крутилось:
Лефортовский кондитерский комбинат. Спокойный среди бурь.
1. Вы хотите знать какое потребуется время и сколько нужно ресурсов на то, что никак не сформулировано?
2. Вы хотите иметь ответственного партнера, которого при этом легко «ампутировать»?
если он мне тыкает ТЗ = отказ от ответственности = «признание, что проект он ни осилит, и заранее делает — больше бумаги чище ....»
Тех. задание — это тех. задание, а отказ от ответственности — это отказ от ответственности. Они не равны, не взаимозаменяемы, это не одно и тоже…
Подобные умозаключения не логичны. Ошибочны. Как следствие, остальные выводы ошибочны. Продолжать читать дальше этой строки, не имеет смысла…
Есть два пути: 1) идти на Freelance и самостоятельно нести там все риски того, что у вас возьмут предоплату и киданут или задолбаются от вас жёстко и пошлют подальше; 2) обращаться в компанию и смириться с тем, что она работает по бизнес-логике, и бегать за вами там никто не будет, и да, разработчики там работают профессионально, по ТЗ, по часам и с 5 и более заказчиками. Хотите индивидуальной работы? Отлично! Оплачиваете отдельную штатную единицу по часам с повышенной ставкой. И, конечно, никто вам никогда не даст возможности трахать мозги квалифицированному персоналу.
- какой версией Гугл Транслейта вы пользуетесь?
- сколько компаний\студий\фрилансеров вам требуется перебрать для запиливания всего проекта и сколько времени у вас уходит на согласование конечного ТЗ?
Заранее спасибо.
Окончательное ТЗ при используемом подходе это исходный код
В какой версии продукта код становится окончательным?
красивая девочка «бизнес аналитик» с любимым вопросом «а Вамзачем»
Её красота мешала вам отвечать на вопрос? ;)
Те московские разработчики пытались с вами по-человечески разговаривать, насколько я могу судить, не обращая внимания на ваш феерический клубок последствий отключения всех систем головного мозга, за исключением лимбической (сужу по вашему стилю изложения — не обижайтесь, вы в этом не одиноки — за пределы изобретения Гутенберга ещё многие люди на планете не выбрались).
Вам же стоит «немного» больше думать
1. Заказная разработка — это тоже бизнес. Ну совсем грубо говоря, владелец такой конторы покупает время у своих сотрудников и продаёт его вам, с налогами и прибылью. Если он ошибся при оценке стоимости разработки, он покупает больше времени, но продаёт его вам за тот же фиксированный прайс. Таким образом, оплачивая лишние часы разработчиков из своего кармана.
2. Соответственно, предложенная вами схема без ТЗ, без четких требований к продукту, но с фиксированными сроками и ценой, проканает только с совсем неопытными фрилансерами. Каждый юный предприниматель один-два раза накалывается на проектах с отсутствием ТЗ и всё, резко перестаёт быть волшебником в голубом вертолёте.
3. Рынок качественной разработки — это рынок продавца. Нравится вам или нет. В любой грамотной конторе огромная куча входящих заявок сразу идёт в корзину, если заказчик выглядит, просто выглядит, неадкватом. Либо же, если у заказчика явно есть деньги, в смету закладываются трёхкратные риски и огромный бонус «за вредность». Так что вам придётся либо играть по правилам исполнителя, либо очень сильно переплачивать.
4. Чем дальше вы продвинулись по этапам разработки, тем больше вы влипли. Исполнитель свои деньги ну плюс-минус получил, пусть и без прибыли, а у вас пока на руках лишь частично готовый продукт, использовать который нельзя. Если вас осенит гениальная идея, или если в ТЗ обнаружится ошибка — не важно, по чьей вине, или по какой-то ещё причине вы решите поменять ТЗ или выдвинуть новые требования — вам вежливо улыбнуться, выдвинут смету на доп. работы и пригласят в кассу. Не нравится? До свидания.
5. Доделывать проект в другой компании будет кратно дороже — ну, потому что новым разработчикам нужно время, чтобы въехать в тематику. Не потому, что разработчики такие злые или жадные, просто см. п. 1.
5. Однако, многие владельцы компаний друг с другом знакомы хотя бы через третьи руки, и не обломаются позвонить бывшему исполнителю узнать вашу характеристику, если вы к ним придёте «дорабатываться». Если вы вели себя как м… к, с вами просто никто не будет разговаривать.
Такие пассажиры далеко не всегда на первых встречах выглядят неадекватами или жесткими бизнесменами с яйцами (если орел я выиграл, а если решка ты проиграл).
На первых встречах они могут быть такие улыбчивые, позитивные, отзывчивые. Что-нибудь в духе:
— Да, я вас не обижу
— Да, от меня будет постоянный поток заказов
— Да, я всегда на стороне исполнителя
— Да, я ищу себе надежного партнера для долгосрочного сотрудничества
— Да, я не против ТЗ, просто пока толком непонятно и нужно нащупать рынок вместе с моим новым прекрасным партнером!
А если он еще и по знакомству пришел (а они любят прийти по знакомству), то эта конфетно-карамельная история бывает уносит в ванильные дали не только бывалых фрилансеров, но и опытных менеджеров и директоров малых и средних компаний, а бывает и крупных -)
Если вас осенит гениальная идея, или если в ТЗ обнаружится ошибка — не важно, по чьей вине, или по какой-то ещё причине вы решите поменять ТЗ или выдвинуть новые требования — вам вежливо улыбнуться, выдвинут смету на доп. работы и пригласят в кассу. Не нравится? До свидания.
Добавлю к этому, что вам скажут еще и сроки, которые могут быть весьма далекие т.к. команда, которая занималась вашим проектом должна перейти на другой проект, по которому уже оплачен аванс. Иными словами, в ряде случаев серьезные переработки в короткие сроки иногда сделать не получится даже за большие деньги т.к. у разработчиков другие планы.
Один из пунктов — «Подходящий вариант оплаты», с вариантами:
- «Еженедельная фиксированная оплата»
- «Фиксированная сумма за ТЗ, проект по согласованному техзаданию без доплат (требуется подробнейшее техзадание в файле)
- »Почасовая оплата каждого этапа по согласованному техзаданию с дополнительной почасовой оплатой любых изменений задания и переделок"
- «Стоимость рабочего часа со скидкой. Но большой\длительный проект (больше 99 рабочих часов) с поэтапной периодической оплатой тщательной работы с возможностью изменения техзадания и переделок»
Разумеется, подавляющее большинство заказчиков выбирает второй пункт с фикс. суммой за проект.
Так вот если они выбирают его, но отлынивают от составления ТЗ в файле — я сразу им напоминаю об этом несоответсвии, и 95% «пропадают в дали», переставая тратить моё время. Но малая толика «адекватов» все-таки остается, и обычно это наиболее серьезные и платежеспособные заказчики.
И так же достаточно заказчиков осознанно выбирающих последний пункт. И если работа с ними начинается — им уже даже приятно делать скидки и округления сумм вниз.
На втором шаге я переношу бизнес требования в вики и создаю к ним на форуме тему для проекта, в который постю все свои вопросы по бизнес требованиях в рамках полноты и логической непротиворечивости. На это стадии отсекаются неадекваты, осилившие бизнес требования, но не способные
Дальше просто интерактивный функциональный прототип реализующий бизнес требования.
Тест заказчиком
А дальше разработка на основании прототипа. Прототип выступает как часть ТЗ и даже даже дает метрику для оценки стоимости разработки.
ТЗ высокой четкости