Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Ненавижу работать по фиксированному тз. Это никогда не работает для проектов с разработкой более 2 недель.
Советую присмотреться к DDD
Советую присмотреться к DDD
Я так понимаю ТЗ и DDD не конфликтуют, скорее они коррелируют друг с другом. ТЗ можно использовать для описания предметной области и разруливания связей между объектами, для программиста это наверное самое главное, вникнуть в предметную область, понять что хочет заказчик.
Поэтапная разработка предполагает постоянное допиливание ТЗ, просто это допиливание строго регламентировано, прошел спринт, покрыли тестами, сдали, допиливаем ТЗ по новым фичам, новый спринт и т.д.
Опять же по своему опыту скажу, что многие руководители(заказчики, менеджеры) не понимают что невозможно написать ТЗ сразу, поэтому для них все эти допиливания и новые траты кажутся косяками именно разработчика. Так вот наша основная задача, переложить эту ответственность им на плечи сразу, о чем автор и пишет. Загодя мы разграничиваем зону ответственности уменьшая риски, как их так и наши.
Поэтапная разработка предполагает постоянное допиливание ТЗ, просто это допиливание строго регламентировано, прошел спринт, покрыли тестами, сдали, допиливаем ТЗ по новым фичам, новый спринт и т.д.
Опять же по своему опыту скажу, что многие руководители(заказчики, менеджеры) не понимают что невозможно написать ТЗ сразу, поэтому для них все эти допиливания и новые траты кажутся косяками именно разработчика. Так вот наша основная задача, переложить эту ответственность им на плечи сразу, о чем автор и пишет. Загодя мы разграничиваем зону ответственности уменьшая риски, как их так и наши.
Именно так. Мы исполним любой каприз — но только за ваши деньги. Список «капризов» — в ТЗ, хотите его изменить — изменяйте ТЗ.
А иначе выяснится, что то, на что вы угробили несколько сот человеко-часов… было просто «пожеланием», за которое заказчик, так и быть, долларов 20-30 готов отвалить.
А иначе выяснится, что то, на что вы угробили несколько сот человеко-часов… было просто «пожеланием», за которое заказчик, так и быть, долларов 20-30 готов отвалить.
Выступал заказчиком несколько раз, и по-моему опыту — ТЗ это лишь список основных функций (1, 2, 3) проекта, возможно с некими эскизами дизайна форм или отчетов. ТЗ практически никогда не описывает поставленную задачу исчерпывающе, если там, конечно, не задание на разработку калькулятора или ТЗ не стоит как половина стоимости всей разработки.
Когда дело доходит до контроля тех или иных этапов, выполняемых по ТЗ, довольно часто оказывается, что если ТЗ не 100+ страничный документ, что исполнитель/команда исполнителей не так поняла или интерпретировала те или иные пункты из ТЗ. Иногда бывает, что исполнитель не может выполнить один-в-один как написано в ТЗ, в связи с техническими ограничениями, тогда идет согласование между тем, что хотелось и тем, что получилось (и приведение этих двух вещей к общему знаменателю).
"… поднимает базу, если та падает, делает мелкие фиксы. Если намечается хоть какой-нибудь мало-мальски большой баг — сразу в эстимейт..." т.е. баг команды, в отличие от фич заказчика, также должен быть оплачен заказчиком? Оригинально.
Когда дело доходит до контроля тех или иных этапов, выполняемых по ТЗ, довольно часто оказывается, что если ТЗ не 100+ страничный документ, что исполнитель/команда исполнителей не так поняла или интерпретировала те или иные пункты из ТЗ. Иногда бывает, что исполнитель не может выполнить один-в-один как написано в ТЗ, в связи с техническими ограничениями, тогда идет согласование между тем, что хотелось и тем, что получилось (и приведение этих двух вещей к общему знаменателю).
"… поднимает базу, если та падает, делает мелкие фиксы. Если намечается хоть какой-нибудь мало-мальски большой баг — сразу в эстимейт..." т.е. баг команды, в отличие от фич заказчика, также должен быть оплачен заказчиком? Оригинально.
>> баг команды, в отличие от фич заказчика, также должен быть оплачен заказчиком? Оригинально.
Именно так, и никак иначе.
Именно в этом состоит послегарантийная техподдержка.
Вам же телевизор никто не будет бесплатно чинить после истечения гарантии.
Другое дело, что может быть фиксированная оплата техподдержки, где есть обязательство обеспечить функционирование системы, и неважно, какой трудоемкости требует исправление критических багов.
Именно так, и никак иначе.
Именно в этом состоит послегарантийная техподдержка.
Вам же телевизор никто не будет бесплатно чинить после истечения гарантии.
Другое дело, что может быть фиксированная оплата техподдержки, где есть обязательство обеспечить функционирование системы, и неважно, какой трудоемкости требует исправление критических багов.
Распространенное заблуждение. Исполнители часто путают работу над проектом с продажей коробочной версии продукта. Телевизор же собирается не по ТЗ заказчика, а является продуктом разработки, тестирования и массового производства. Это как купить лицензионную ОС Windows, а потом платить Microsoft за каждый патч.
Вы во многом правы, но в реальности получается так, что есть какой-то гарантийный бесплатный период поддержки (у нас это 1 месяц), за который заказчик и реальные пользователи (продакшн) должны по-идее выявить основные баги. Далее поддержка естественно платная, у нас по модели Time&Materials (оплата за часы).
Простите, но у Вас явное противоречие, приводите пример для коробочного продукта с бесплатными патчами (которые заканчиваются, см. XP), возражая против платной техподдержки разработанного по ТЗ.
Придется рассказать азы.
Заказчик после процедуры сдачи продукта подписывает акт приемки.
Затем начинается период гарантийной техподдержки.
После истечения которого все работы по продукту платные, в т.ч. исправление багов, а, точнее, обеспечение функционирования продукта в рамках ТЗ.
Все отступления от этого — добрая воля разработчика и/или прогиб под заказчика.
Придется рассказать азы.
Заказчик после процедуры сдачи продукта подписывает акт приемки.
Затем начинается период гарантийной техподдержки.
После истечения которого все работы по продукту платные, в т.ч. исправление багов, а, точнее, обеспечение функционирования продукта в рамках ТЗ.
Все отступления от этого — добрая воля разработчика и/или прогиб под заказчика.
если там, конечно, не задание на разработку калькулятора или ТЗ не стоит как половина стоимости всей разработкиВообще-то исчерпывающее ТЗ, выстраданное, осмысленное и принятое Заказчиком — это считайте половина проекта. Просто не получится Заказчику объяснить что это стоит половину денег. Да и Исполнитель не всегда это понимает.
Но это работает если Заказчик действительно знает чего хочет. Если нет — нужно сажать его на короткие итерации или поресурсную оплату.
И это правильно. ТЗ должно быть предельно подробным! Иначе не избежать путаницы, косяков (в понимании клиента и реально являющихся таковыми), взаимных обид и, в худшем случае, судов и тому подобных неприятностей. Лично приходилось лицезреть едва ли не до суда дошедшее разбирательство из-за того, что клиенту казалось, что на корпоративном сайте анимационный элемент кажется зернистым, а страницы выводятся на печать без логотипа компании в шапке. А еще очень хорошее дело — дополнения к договору и доп. соглашения, если реально нужны доработки.
Наше ТЗ фиксировано не с точки зрения фич, а с точки зрения «легальности», т.е. если никто ничего не изменит до часа Ч, то сорьки, вы нас попросили это — мы сделали это. В процессе разработки идёт непрерывное обсуждение определенных моментов с заказчиком и определенные правки. Если вдруг глобальные правки — то переоценка данной задачи.
Помню, кстати, один случай, когда мы работали не напрямую с заказчиком, а с его заместителем. И он где-то попросил сделать какую-то ненужную хрень, а мы взяли и сделали. А когда пришло время сдавать проект, ему крайне не понравилась эта вещь, и он ругался, кричал, обзывался и отказывался платить. Мы ткнули его лицом в то, что это было зафиксировано в документе, мол, к нам никаких претензий, ваш представитель попросил и на наши просьбы передумать он нам ответил, что инфа сотка, дирик будет в восторге ёпт. Ну и ткнули лицом в ТЗ и e-mail логи, сказали, извините — но платите, люди же работали. Таки заплатил, до сих пор работаем с ним, правда, часть задач он перевёз в Индию.
Помню, кстати, один случай, когда мы работали не напрямую с заказчиком, а с его заместителем. И он где-то попросил сделать какую-то ненужную хрень, а мы взяли и сделали. А когда пришло время сдавать проект, ему крайне не понравилась эта вещь, и он ругался, кричал, обзывался и отказывался платить. Мы ткнули его лицом в то, что это было зафиксировано в документе, мол, к нам никаких претензий, ваш представитель попросил и на наши просьбы передумать он нам ответил, что инфа сотка, дирик будет в восторге ёпт. Ну и ткнули лицом в ТЗ и e-mail логи, сказали, извините — но платите, люди же работали. Таки заплатил, до сих пор работаем с ним, правда, часть задач он перевёз в Индию.
Кстати, на счёт DDD спасибо)
По неопытности была похожая ситуация, только более абсурдная и сложилось все несколько иначе.
Работали не на прямую с заказчиком, а с представителем, утвердили ТЗ и сроки. Идет работа над дизайном сайта, вносятся правки, все вроде бы как обычно. Сайт уже сверстан, настраиваются последние штрихи и вдруг возникает сам заказчик и говорит: «Ваш дизайн говно, переделывайте».
Никакие доводы не были услышаны, в итоге заказчик без сайта, мы кое-как вышли в ноль.
Работали не на прямую с заказчиком, а с представителем, утвердили ТЗ и сроки. Идет работа над дизайном сайта, вносятся правки, все вроде бы как обычно. Сайт уже сверстан, настраиваются последние штрихи и вдруг возникает сам заказчик и говорит: «Ваш дизайн говно, переделывайте».
Никакие доводы не были услышаны, в итоге заказчик без сайта, мы кое-как вышли в ноль.
Как то была обратная ситуация. Делали лет 6-7 назад сайт для «дочки» одной компании. У головной компании — брендбук, где листов 100 посвещено сайту. Какие шрифты, какие цвета, какие отступы от картинок и пр. Как должны оформляться новости/галереи и т.д. Шикарная штука.
Когда непосредственный заказчик просил вкорячить очередную фичу в проект — с него требовалось письмо официальное, что он по своей инициативе отступает от общих требований группы компаний и либо согласовал это, либо берёт на себя всю ответственность. В итоге 99% «хотелок» удалось таким образом завернуть.
Когда непосредственный заказчик просил вкорячить очередную фичу в проект — с него требовалось письмо официальное, что он по своей инициативе отступает от общих требований группы компаний и либо согласовал это, либо берёт на себя всю ответственность. В итоге 99% «хотелок» удалось таким образом завернуть.
Вопрос к автору: Такая схема работы на какие сроки и на какие деньги? У меня сложилось впечатление, что речь идёт о проектах типа дизайна домашней странички. А если проект на год?
А на каком этапе заказчик понимает стоимость разработки? Вы оценки проводите только на третьем этапе, а мне почему-то всё время попадаются клиенты, которым надо стоимость ещё дна нулевом этапе.
А другие денег не считают? И нет, я не говорю про СНГ.
По моему опыту первое что хочет знать заказчик — это стоимость, второе — срок. И это в любой стране.
Дилетантство как правило проявляется в непременном желании узнать эти две вещи без постановки задачи, круглые глаза в ответ на сумму и конечно решения вроде «знакомый Вася это сделает за сто баксов и неделю».
Дилетантство как правило проявляется в непременном желании узнать эти две вещи без постановки задачи, круглые глаза в ответ на сумму и конечно решения вроде «знакомый Вася это сделает за сто баксов и неделю».
Золотые слова!
Не знаю, о каких Вы бизнесах говорите и почему сразу говорите о дилетантстве. Я не так много компаний видел, конечно, но все они плевали на издержки и всё вкладывали в развитие новых клиентов. Но это в Москве. Может быть в Махачкале, всё иначе.
Выбор модели поведения бизнеса зависит больше от рынка и от размера самой компании. Серебряной пули, как всегда нет и любому бизнесу приходится балансировать между сокращением издержек и ростом.
Выбор модели поведения бизнеса зависит больше от рынка и от размера самой компании. Серебряной пули, как всегда нет и любому бизнесу приходится балансировать между сокращением издержек и ростом.
На этапе выставленного приблизительного времени разработки. Каждая задача оценивается.
Лично у нас практикуется понятие «предварительных оценок». Как правило это «вилка» по срокам и бюджету, которую мы формулируем после составления первого документа проекта, который нахываем «бриф» (BSD). По моему опыту для любого адекватного заказчика на первом этапе этого более чем достаточно. Если же требуют точных и итоговых оценок до этапа проектирования и написания ТЗ, то лучше с таким заказчиком вовсе не связываться.
Как вы делаете эстимейт, если заказчик хочет сайт «как у Васи»? То есть он еще не решил работать с вами или нет, а только приценивается. Насколько четко вы укладываетесь в эстимейты? Что делаете, если потратили больше времени, чем планировали?
Есть другой вариант: называете вилку цен и вилку сроков. Далее идет уточнение и сужение вилки. Если заказчик не знает чего хочет, и не понимает зависимости времени и цены от сложности, то с ним лучше не работать.
Насколько я понимаю, в этой ветке ведется обсуждение постановки задачи вида: «сайт как у дяди Васи» с последующим точных соблюдением изначальных оценок. Ни о каком ТЗ здесь и речи не идет) PerlPower совершенного справедливо заметил, что в таком положении любой эстимейтор фактически вынужден солгать, потому что в реальности слишком мало информации, чтобы была хоть малейшая вероятность выдать точную оценку.
К счастью, когда я пришёл работать в компанию, то она уже переросла «фриланс-на-снг» и теперь занимается «фринлансом-на-юса».
Но если бы такое случилось, то выставили бы неадекватный ценник, а потом натянули бы шаблон на CMS. Такие дела.
Но если бы такое случилось, то выставили бы неадекватный ценник, а потом натянули бы шаблон на CMS. Такие дела.
«все фичи из третьего пункта будут неадекватно заэстимейчены» — достойно плаката :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с клиентом или «почему вы не сделали то, что мы просили?»