Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 110
Что-то сумбурно вышло у вас, но замена ТЗ чем-нибудь более понятным и интерактивным уже давно витает в воздухе.
Есть немного. Записывал по горячему.
Нельзя начинать разработку пока не увидишь всю картину в целом. Начальник отдела скорее всего знает свой участок, и не больше. Поэтому карта набросок проблем может перерасти в отдельные несвязные участки программы.
Поэтому ТЗ должно начинаться с ключевого лица которое видит всю схему, и потом опускаться ниже до начальников отдела наполняя схему деталями.
Поэтому ТЗ должно начинаться с ключевого лица которое видит всю схему, и потом опускаться ниже до начальников отдела наполняя схему деталями.
Ну, это смотря на каком уровне вы находитесь сами. :)
Хотя в целом согласен, начинать надо с вершины айсберга.
Хотя в целом согласен, начинать надо с вершины айсберга.
Сейчас всей командой переходим с одного места работы на другое. В связи с чем перелопачиваю огромное количество литературы по управлению проектами. И знаете, очень большое количество авторов склоняется к тому, что НЕЛЬЗЯ говорить с директором, главным бухгалтером, начальником производства! Т.к. они не знают что творится внизу. Имея опыт разработки небольшой ERP могу это говорить с еще большей уверенностью. Общаешься с главным технологом: «Делать так, так и так». Приходишь к начальнику отдела входного контроля: «Кто вам сказал такую глупость! Вы вообще МИ6 читали? там же все не так!». А Главный технолог даже и не знал про это тдокумент. Поэтому общаться надо всегда с пользователями будущей системы, ведь именно их работу вы будите автоматизировать. А с начальником, да, тоже надо, но на тему какие выхоные данные и в каком виде ему нужны.
Скажите, а насколько большой у вас проект? И что происходит, если заказчик недоволен резултатом, как решаются проблемные и спорные ситуации? Если есть спеки, то можно всегда доказать, что все сделано именно так, как предполагалось, а если их нет, то что делать?
Последний который делаем, для гос-структур. Насколько большой мы не знаем. Пока не иссякнет или финансирование, или желание развивать его дальше.
У нас не было такого, что заказчик не доволен результатом. Есть мелкие недочеты по мнению заказчика, но в целом все счастливы. Причина в том, что заказчик понятия не имеет, что он хочет, как он это видит, как лучше всего реализовать, и что собственно мы реализовываем. Мы предлагаем прототипы — он только потом понимает такое он хотел или нет.
Спек нет. Есть только карты проблем. Мы решаем проблему, а не выполняем действия по спеке. Полная свобода выбора.
У нас не было такого, что заказчик не доволен результатом. Есть мелкие недочеты по мнению заказчика, но в целом все счастливы. Причина в том, что заказчик понятия не имеет, что он хочет, как он это видит, как лучше всего реализовать, и что собственно мы реализовываем. Мы предлагаем прототипы — он только потом понимает такое он хотел или нет.
Спек нет. Есть только карты проблем. Мы решаем проблему, а не выполняем действия по спеке. Полная свобода выбора.
Понятно. Я бы за такие проекты не взялся, особенно для госсутрктур :) Если заказчик не знает, чего хочет, то спеки, хотя бы общие, мы бы писали сами, потом утверждали, и только потом дев. Задержка только для первой версии значительная. Когда начинается тестирование за несколько месяцев до релиза, начинается и обсуждение изменений в новой версии, и к новому циклу разработки спеки для программистов готовы. Вам удачи! Чтобы и впредь с заказчиками проблем не было :)
Ну и еще вопрос. Каким образом у вас поставлены процессы, связанные с юзабилити, дизайном интерфейса и т.д. Неужели тоже программисты сами решают эти вопросы? Если не программисты, то это уже почти спека — без четкого понимания того, что будет, макет не нарисуешь.
Ну и еще вопрос. Каким образом у вас поставлены процессы, связанные с юзабилити, дизайном интерфейса и т.д. Неужели тоже программисты сами решают эти вопросы? Если не программисты, то это уже почти спека — без четкого понимания того, что будет, макет не нарисуешь.
Мы создали еще три года назад вполне удачный UI, теперь используем этот подход во всех остальных проектах.
А по поводу того, что заказчик не значет чего хочет — этого бояться не нужно. Это наоборот плюс. Он будет доверять вам разработку, а значит и проблем с ним будет меньше. Он не будет учить вас делать вашу работу. :)
А по поводу того, что заказчик не значет чего хочет — этого бояться не нужно. Это наоборот плюс. Он будет доверять вам разработку, а значит и проблем с ним будет меньше. Он не будет учить вас делать вашу работу. :)
Да уж, гораздо хуже, когда он думает, что знает чего хочет=( Особенно это заметно в крупных компаниях, когда переписывается основной рабочий инструмент. Тогда начинается ад=((
А зачастую это круто. Особенно когда речь идет об автоматизации документооборта или бухгалтерии для компании из страны, даже географическое положение которой ты не знаешь, не говоря уже о тонкостях законодательства. Половина проблем снимается.
Ну это предметная область, это по любому нужно у заказчика узнавать (особенно в России, где все делается через совершенно разные Ж). Хуже, когда заказчик хочет старый добрый костыль, который просто невозможно впихнуть в новую систему, а переучиваться не желает.
Просто нельзя давать мелким менеджерам руководить развитием проекта. Они и на ТЗ-то плюют (это кстати часто делают и «большие начальники»), но оно хоть как-то помогает укладываться в сроки.
Просто нельзя давать мелким менеджерам руководить развитием проекта. Они и на ТЗ-то плюют (это кстати часто делают и «большие начальники»), но оно хоть как-то помогает укладываться в сроки.
С документооборотом (особенно внутренним), кстати, это не всегда круто. Говорят «нам нужен такой-то документ в 3-х экземплярах», а потом оказывается что только один из них нужно по закону в архиве держать, а второй нужен чтобы отнести менеджеру в другой отдел, чтобы он на его основе механически составил другой, а третий себе в папочку «на всякий пожарный». И это ещё нормальный случай, когда документ действительно нужен по закону.
Я понял вашу позицию :) Выглядит оно, конечно, интересно. Но я так привык к своему тазику! Он обеспечивает и стабильный доход, и отпуск вовремя, и отсутствие головной боли. Возможно мы попробуем ваш подход на небольшом проекте, но, честно говоря, стремно очень :)
Не советую делать это на мелких проектах. Чем больше объем, тем явнее выгода от такого подхода.
Все дело в том, что срок вникания в процессы заказчика больше чем срок составления простого ТЗ, но гораздо меньше чем срок создания большого ТЗ. Хотя, если найти хорошего аналитика, то все пойдет гораздо быстрее.
Все дело в том, что срок вникания в процессы заказчика больше чем срок составления простого ТЗ, но гораздо меньше чем срок создания большого ТЗ. Хотя, если найти хорошего аналитика, то все пойдет гораздо быстрее.
Спеки, конечно, хорошая бронь для задницы. Заказчик бьется в истерике: «Это совсем не то, что я хотел», а мы ему: «Ну как же, вот ваша подпись, это именно то, что вы хотели. Если желаете — можем составить ТЗ на модернизацию» :) В общем никакой синергии и взаимного удовлетворения. А учитывая, что ТЗ обычно пишутся разработчиками для разработчиков и с гигантским количеством воды, то заказчик читает их наискосок.
Я, например, последние года 3-4 работаю без ТЗ. Составляется рамочный договор, который описывает только организационную сторону (порядок оплаты и т.п.) и не делает из проекта кабалы для любой из сторон. Дальше короткими итерациями — прототип — понравилось — счет-акт. Получается ерунда — выявили на ранней стадии с минимальными затратами для сторон.
Я, например, последние года 3-4 работаю без ТЗ. Составляется рамочный договор, который описывает только организационную сторону (порядок оплаты и т.п.) и не делает из проекта кабалы для любой из сторон. Дальше короткими итерациями — прототип — понравилось — счет-акт. Получается ерунда — выявили на ранней стадии с минимальными затратами для сторон.
:) И это чертовски хорошо работает, правда?
Атож :) Риск, конечно, определенный есть, но это небольшая плата за синергию. К тому же те заказчики, которые работали без ТЗ, с ТЗ уже работать не хотят, поэтому никуда не уходят. Что освобождает от необходимости работать с теми, кто без ТЗ себе жизни не представляет. Вменяемые подрядчики в основном соглашаются хотя бы на попробовать, благо риск минимален. А невменяемых я оставляю для любителей экстрима. Там хоть с ТЗ, хоть без него :) Буквально пару недель назад я получил убойный аргумент: «Ну мы же коммерческая организация, нам без ТЗ нельзя». Как будто до этого я работал только с благотворительными :) В общем не знают люди толком, зачем им это ТЗ нужно.
Понимаете в чем дело, иногда действительно без ТЗ нельзя. Например, в некоторых государствах существуют структуры, берущие под крыло IT-конторы, вроде Сколково, дающие классные льготы по налогам и прочие плюшки, но они могут требовать от компании открытости и много документации, вплоть до ТЗ по проектам. Так что наличие/отсутсвие ТЗ — не такой уж и однозначный критерий вменяемости конторы.
Да, это отличный тазик сзади! И этот тазик иногда спасает от проникновения чужеродных предметов в организм :))) Сократить количество документации я бы согласился, если мы с заказчиком работаем давно, хотя бы 1-2 версии продукта зарелизили. Иначе как-то стремно. Можно просто попасть на бабки, особенно если fixed-price.
Вода в ТЗ это, конечно, плохо. Я последние годы работал так: состалвялись списки фичей, чего заказчик хочет. По этим фичам разрабатывался примерный дизайн приложения — окна, воркфловы и т.д. На этом этапе все легко менялось, но заказчик уже видел все, что он получит. Зачастую даже в динамике — на HTML+JScript или на флеше. Когда он становился happy, по этому всему составлялись подробные спеки для программеров, и начинался дев десктопного приложения. Собственно, заказчик уже в самом начале, за полгода, знал, что он получит. Поэтому кабалы никакой не было, и мы тоже были защищены.
Вода в ТЗ это, конечно, плохо. Я последние годы работал так: состалвялись списки фичей, чего заказчик хочет. По этим фичам разрабатывался примерный дизайн приложения — окна, воркфловы и т.д. На этом этапе все легко менялось, но заказчик уже видел все, что он получит. Зачастую даже в динамике — на HTML+JScript или на флеше. Когда он становился happy, по этому всему составлялись подробные спеки для программеров, и начинался дев десктопного приложения. Собственно, заказчик уже в самом начале, за полгода, знал, что он получит. Поэтому кабалы никакой не было, и мы тоже были защищены.
ТЗ в виде прототипа — это ж совсем другое дело. К сожалению, у нас культура составления ТЗ такова, что заказчика стараются запутать, дабы повысить бронированность задов :) Сравнительно недавно наблюдал откровенный наезд одного председателя правления банка на составителей ТЗ, суть которого в емких словах звучала как: «вы по-русски вообще изъяснятся умеете»? Эти горе-составители начали с того, что назвали ТЗ «дизайн стратегий». Им привычный термин показался не таким емким :)
Да. «В теории» кажется что ТЗ и комплект OMG гостированных документов которые оно за собой влечёт кого-то от чего-то страхуют. Но часто — это не так)
Ситуация: Есть «ТЗ» (в широком смысле комплект проектной документации). Заказчик говорит «это не то, что я хотел», подрядчик говорит «это то что заказывали». Что дальше?
1)Идти в суди там трясти этими документами? Это смешно: юристы обойдутся обеим сторонам дорого, заказчик будет очень долго ждать систему, подрядчик очень долго будет ждать деньги. Судья в наших квадратиках и тсрелочках ничего не понимает — будет привлечёны «эксперты», причём с каждой стороны, которые будут говорить противоположное. Решение не удовлетворит одну из сторон — она его обжалует и всё по новой.
В итоге — у нас есть ТЗ, но и те и другие проиграли.
2)Договариваться и СОВМЕСТНО искать выход из сложившейся ситуации. Но первоначальное ТЗ тут кабэ совсем не причём и опять же никому ничего не гарантирует.
Ситуация: Есть «ТЗ» (в широком смысле комплект проектной документации). Заказчик говорит «это не то, что я хотел», подрядчик говорит «это то что заказывали». Что дальше?
1)Идти в суди там трясти этими документами? Это смешно: юристы обойдутся обеим сторонам дорого, заказчик будет очень долго ждать систему, подрядчик очень долго будет ждать деньги. Судья в наших квадратиках и тсрелочках ничего не понимает — будет привлечёны «эксперты», причём с каждой стороны, которые будут говорить противоположное. Решение не удовлетворит одну из сторон — она его обжалует и всё по новой.
В итоге — у нас есть ТЗ, но и те и другие проиграли.
2)Договариваться и СОВМЕСТНО искать выход из сложившейся ситуации. Но первоначальное ТЗ тут кабэ совсем не причём и опять же никому ничего не гарантирует.
А по-моему "… краткое изложение задач для решения, написанное вольным стилем." может вылиться в недопонимание между клиентом и разработчиком, и в дальнейшем грозит дополнительными доработками и исправлениями
Недопонимание может возникнуть по двум причинам: вы мало времени потратили на изучение проблем заказчика и вы не смогли вникнуть в его бизнес-процессы.
Доработки в XP — норма. Мы особо не переживаем, если нам придется выкинуть к черту двухнедельный результат работы, если его можно сделать еще более удобным для заказчика и без костылей
Доработки в XP — норма. Мы особо не переживаем, если нам придется выкинуть к черту двухнедельный результат работы, если его можно сделать еще более удобным для заказчика и без костылей
А если речь идет о месяце работы, или о нескольких месяцах? Сколько потраченного времени вы готовы выкинуть, что реализовать то, что клиент «додумал» в процессе разработки, за неделю до сдачи готового прокета?
Пока не иссякнет или финансированиеговорит, что время хоть тратится исполнителем, но оно оплачивается заказчиком :)
Нет сроков сдачи проекта. Проект находится в постоянной стадии «готовый», потому что оплачивается время разработки, а не количество строк кода.
И вы на любой стадии проекта, готовы переделать все с нуля?
Да, потому что работа идет на результат. Сделал плохо — прощай проект. Сделал хорошо — работаешь дальше. Всем выгодно.
Рефакторинг не страшное слово. К этому многие тяжело привыкают, но потом приходится останавливать, чтобы не перегибали палку в желании еще что-то переделать
Рефакторинг не страшное слово. К этому многие тяжело привыкают, но потом приходится останавливать, чтобы не перегибали палку в желании еще что-то переделать
Если все это время оплачивается клиентом, то конечно так даже лучше. Чем больше он думает, тем больше он платит. А если клиент оплачивает проект а не время разработки, и за дополнительную работу платить не готов?
То мы не беремся за такие проекты. Они не выгодны нам и бесполезны для заказчика, как показывает практика (наша в том числе).
Вот видите, вы не беретесь, следовательно не знаете, что как раз для таких проектов и нужно ТЗ в первую очередь. Я работаю именно на таких проектах, и вместо ТЗ у меня невнятные просьбы менеджера проекта. Поверьте, это ужасно.
Т.е. ваша методология работы без ТЗ, и соответственно с рисками выкинуть кучу работы с помойку, не работает на проектах с фиксированными сроками сдачи и оплатой по факту?
А по-моему зачастую бывает наоборот. Если ТЗ написано заказчиком, то будет куча ненужных подробностей предметной области, но мало действительно технических требований. Если исполнителем, то ТЗ будет перегружено техническими терминами и спецификациями, за которыми заказчик не увидит, а что собственно выйдет в итоге. А чтобы не было недопонимания нужно сформулировать проблему, сделать «на коленке» первый набросок решения, закоммитить и показать заказчику — он поправит что не так сразу, а не когда будет написано 100500 вылизанных строк кода с обработкой всех возможных нетипичных ситуаций и т. п. Жаль что не многие соглашаются по такой схеме работать.
Не надо бросаться из крайности в крайность. ТЗ нужно хотя бы для того, чтобы понять объем будущих работ. А как вы его напишете, будет зависеть от вас. А еще ТЗ — это гарантия того, что клиент получит именно то, что написано, а не то что он «думал».
Так клиенту же нужно то, что он «думал», а не то, что написано. Ему ехать надо, а не шашечки.
Правильно, только если он передумал, то потом еще заявит разработчику что его «не так поняли», и оплачивать дополнительно он не намерен.
Таких можно наказать в ответ, заставив составить программистопонятное ТЗ. :)
Но лучше с такими вообще не работать. Они не доверяют вам, нет смысла работать с ними.
Но лучше с такими вообще не работать. Они не доверяют вам, нет смысла работать с ними.
Ну одно из требований такого подхода — оплата по затратам, а не по результату. Если видно, что заказчик часто передумывает, а разработку «фэйловых» веток оплачивать не намерен, то закладываем рейт побольше с учётом этих рисков. А частые диалоги с заказчиком (с демонстрацией ему уже сделанного) приводят к тому, что заявить что его «не так поняли» у него возможность появляется на самых ранних стадиях, а не когда всё уже готово.
Educate your Customer.
Если спецификаций нет, то как проводить тестирование? Что считать багом а что фичей?
Что хотите реализовать (покрыто тестами при TDD или иным образом задокументировано) — то фича, что нет — то баг.
Вам может казаться что прога работает правильно и с TDD все будет хорошо, но это может не соответствовать бизнес-логике клиента, а он ее не удосужился формализовать.
Формализовать (итеративно как правило) это скорее моя задача, а не заказчика. Языком фичебагов — приношу заказчику прототип очередной фичи, а он говорит нужна она ему или нужна другая, попутно уточняю что он будет считать багом в реализации этой фичи. Если всё ок, то допиливаю. Если не нужна фича, то удаляю и прихожу в следующий раз с прототипом новой.
Никто не мешает вам создавать спецификацию для разработчика. В ней можете отметить логику функционирования той или иной системы.
Может это и работает, но не у нас. По многим причинам. Менеджеры — такое отродье=((
А до этого я работал где тз вовсе не писалось — было совсем атас=(
А до этого я работал где тз вовсе не писалось — было совсем атас=(
Ну да, как правило составлением FDD занимаются менеджеры. А у них часто нет ни времени, ни интереса, ни таланта писать детально и внятно. Потом возникают проблемы между менеджером и исполнителем: «так я ж тут все описал: „ниже 2 вкладки для 2х статей“ — а оказывается там нужен нехилый нестандартный контрол с кучей свистулек :)
Работник знает только свой процесс, да и тот навязан ему свыше. Начальник же знает процессы всех работников в подчинении и процессы взаимодействия с другими отделами.
Боже упаси, это не начальник тогда, а полный идиот :) Ни один топ-менеджер в здравом уме не будет изучать, как составляется календарь платежей у финансистов или заполняется трудовая книжка у кадровиков. Равно как начальник цеха не будет со всей дотошностью углубляться в процедуры, выполняемые на фрезерных, токарных, шлифовальных, заточных, отрезных и многих других станках. Как впрочем и глава ИТ-отдела не бросится учить все от софтверной архитектуры до администрирования и верстки. Вам не нужен ни начальник ни работник, который предлагает только «перекрасить кнопки». Вам нужен тот, кто называется емким словом «специалист». На нём все держится и он ответит по существу вопроса. Кстати, когда такового находишь, с ним просто чертовски приятно работать :)
Исключение составляют небольшие компании по принципу «все в начале делал гендир, а потом нанял несколько мартышек на рутинные операции».
Заказчик должен быть заинтересован в проекте, в доведении его да рабочего состояния. Часто у него «просто» желание или какой «отмыв» чего-нибудь. Работа заказчика с ТЗ часто чуть ли единственный формальный способ проверки его на «вшивость».
Мне кажется, что вы немного подменяете понятия… ТЗ — это техническое задание, т.е. карта действий по которой разработчик ничего не зная о заказчике и его нюансах сядет и сделает проект.
Из моей практики.
Заказчик пишет не ТЗ, а свои требования списком. Ну что-то вроде
1. Учет товара в магазине по количеству
2. Картанка с товаром на сайте
2. Вывод прайс листа в браузер
3. Ограничить менеджеров в правах
4. Цветовое оформление в желто-синих тонах
Все.
Эти пункты и заносятся в договор.
А вот ТЗ пишется для себя, своих работников. Если проект небольшой и в нем участвует 2-3 сотрудника с нашей стороны, то ТЗ минимально. Т.к. им очень просто сообща работать.
А вот если проект большой, много сотрудников задействовано на длительное время, то без ТЗ уже тяжело будет скоординировать своих собственных сотрудников… Ведь не притащишь все 30 прогеров, дизайнеров и т.д. на переговоры чтобы они «прониклись» проектом? А передавать информацию о том что и как делать необходимо.
Ну а сам процесс у нас примерно как и у вас, в тесном контакте с клиентом и постоянном прототипировании. Плюс этой техники еще и в том, что со временем начинаешь угадывать что именно хотел клиент и приходится меньше лишней работы делать…
Правда все равно периодически попадаются клиенты которых не устраивает любая работа.
Как бороться с такими еще не выявили… очень часто в начале работ все идет отлично и первые пункты проходят на ура… а вот потом начинается… то не так это не так… происходит разрыв договорных отношений… и как правило потом выясняется, что мы уже третьи и четвертые подрядчики которые просто послали клиента и перестали тратить на него свое время.
Но так же периодически попадаются ну очень приличные клиенты. Они открыто говорят, что не знаю как лучше решить их задачу, но готовы оплатить эксперименты. Вот таких бы побольше )))
Из моей практики.
Заказчик пишет не ТЗ, а свои требования списком. Ну что-то вроде
1. Учет товара в магазине по количеству
2. Картанка с товаром на сайте
2. Вывод прайс листа в браузер
3. Ограничить менеджеров в правах
4. Цветовое оформление в желто-синих тонах
Все.
Эти пункты и заносятся в договор.
А вот ТЗ пишется для себя, своих работников. Если проект небольшой и в нем участвует 2-3 сотрудника с нашей стороны, то ТЗ минимально. Т.к. им очень просто сообща работать.
А вот если проект большой, много сотрудников задействовано на длительное время, то без ТЗ уже тяжело будет скоординировать своих собственных сотрудников… Ведь не притащишь все 30 прогеров, дизайнеров и т.д. на переговоры чтобы они «прониклись» проектом? А передавать информацию о том что и как делать необходимо.
Ну а сам процесс у нас примерно как и у вас, в тесном контакте с клиентом и постоянном прототипировании. Плюс этой техники еще и в том, что со временем начинаешь угадывать что именно хотел клиент и приходится меньше лишней работы делать…
Правда все равно периодически попадаются клиенты которых не устраивает любая работа.
Как бороться с такими еще не выявили… очень часто в начале работ все идет отлично и первые пункты проходят на ура… а вот потом начинается… то не так это не так… происходит разрыв договорных отношений… и как правило потом выясняется, что мы уже третьи и четвертые подрядчики которые просто послали клиента и перестали тратить на него свое время.
Но так же периодически попадаются ну очень приличные клиенты. Они открыто говорят, что не знаю как лучше решить их задачу, но готовы оплатить эксперименты. Вот таких бы побольше )))
Выложите пример вашей карты проблем.
Нужен механизм внесения информации в систему для дальнейшего его использования.
Проблема: информация должна фильтроваться от мусора, данные должны быть как можно чище.
Рабочий процесс: есть три группы операторы, надзиратели, пользователи. Операторы вносят информацию, надзиратели проверяют правильность данных, пользователи используют информацию, накопленную в системе. Права доступа должны быть для каждой группы собственные.
Примерно так.
Проблема: информация должна фильтроваться от мусора, данные должны быть как можно чище.
Рабочий процесс: есть три группы операторы, надзиратели, пользователи. Операторы вносят информацию, надзиратели проверяют правильность данных, пользователи используют информацию, накопленную в системе. Права доступа должны быть для каждой группы собственные.
Примерно так.
Вот как раз ТЗ и определяет, что такое «мусор», нужно ли его куда-то складировать или сразу уничтожать и т.д.
Что такое «мусор» и процедуру работы с ним определяет не программа, а документ, который направляется надзирателям в виде приказа.
Программа позволяет выполнять все эти действия не мешая общему бизнес-процессу, как рабочий инструмент
Программа позволяет выполнять все эти действия не мешая общему бизнес-процессу, как рабочий инструмент
«Информация должна фильтроваться от мусора» > фильтровать ее должна программа > программа должна опираться на формальные признаки отличая мусора от не мусора > эти признаки кто-то должен в программу вписывать. Получается надзиратель вписывает их в программу? Я просто провожу аналогию с настройками фльтров спама в почте.
По-моему вы зря совсем выкинули конечных пользователей из процесса создания токового ТЗ. Я согласен с вами, что надо обращаться к тем, кто отвечает за процесс, но после этого стоит еще и с пользователями пообщаться, чтобы понять насколько «видение процессов» со стороны руководства соответствует действительности.
вот вот. Продукт в конечном счете для пользователя все-таки пишется. Руководитель может не догадываться о каком-либо неудобстве, либо забыть о нем, выделив что-то другое. А если пообщаться с пользователем, то можно реализовать то, что поможет сэкономить кучу времени.
Представьте, вас первый раз в жизни посадили в кабину спейс-шатла и спросили, а что вам тут не удобно?
Как вы думаете, вы поможете разработчикам хоть чем-то?
Или пользователь «знает» только две программы: Word и Outlook. Ему подсунули веб-интерфейс. Через время он начнет изливать тонны замечаний, что ваша программа убога и тупая, безумно глючит, нисколько не понятная и разработана с целью подрыва психического здоровья работников. Просто все его привычные паттерны были нарушены и он впадает в коллапс
Как вы думаете, вы поможете разработчикам хоть чем-то?
Или пользователь «знает» только две программы: Word и Outlook. Ему подсунули веб-интерфейс. Через время он начнет изливать тонны замечаний, что ваша программа убога и тупая, безумно глючит, нисколько не понятная и разработана с целью подрыва психического здоровья работников. Просто все его привычные паттерны были нарушены и он впадает в коллапс
если в первый раз, то согласен. А если идет переделка, то надо идти к пользователю.
По поводу веб-интерфейса Word — с большинством современных визивигов я бы тоже повесился на месте пользователей
По поводу веб-интерфейса Word — с большинством современных визивигов я бы тоже повесился на месте пользователей
У меня уже был вариант, когда я по молодости и глупости пошел к пользователю и спросил его, что же не удобно. В итоге я понял простую истину, все что не похоже на старую программу — неудобно. Но старая программа тоже неудобная. Вот такой парадокс пожеланий пользователя.
:)
:)
Переделывал как-то систему на базе FLINT (смесь Access и 1С, но под DOS) под Windows — было неудобно всё («мышка не туда лезет, дабл-клик вообще ужас»). Потом ту же систему переделывал под веб — опять было неудобно всё («делаю дабл-клик и два окна открывается»).
О, я вставил костыль, чтобы даблклик не работал. :) Привычки такие привычки
Да если так рассуждать, то вообще программы переписывать не стоит. А для чего вам голова-то нужна? Никто не говорит о безоговорочном выполнении того, что требует пользователь. Но прислушаться к нему никогда не будет лишним.
И мне кажется вы путаете причину со следствием. Мы ведь начали с того, может ли сказать пользователь что-то хорошее по поводу того, что ему не нравится в существующей программе. А к таким действиям, как одиночный клик — пользователь быстро привыкает и вряд ли будет докучать вас этим. А если и будет, то не стоит обращать на это внимание
И мне кажется вы путаете причину со следствием. Мы ведь начали с того, может ли сказать пользователь что-то хорошее по поводу того, что ему не нравится в существующей программе. А к таким действиям, как одиночный клик — пользователь быстро привыкает и вряд ли будет докучать вас этим. А если и будет, то не стоит обращать на это внимание
Обычные пользователи работают с программами по тетрадке. Не стоит экстраполировать свои знания компьютерной техники на них.
Прекрасный подход, но будет работать только для внутреннего подразделения или для внешнего подрядчика при повременной оплате. Первый вариант я активно применяю последние 5-6 лет.
Свежий подход. Полагаю, что вы еще и не тестируете. Ну а зачем терять время.
А если серьезно, простите, не могу спокойно такое читать после постоянных битв с заказчиками, попытками вспомнить, почему так сделано, а не иначе, постоянным давлением от собственного начальства на нас разработчиков:
— Ну, заказчик позвонил и попросил…
— Пусть письменно подтвердит, поскольку это отменяет предыдущее требование.
и когда проект уже превращается в то, что у вас на картинке и все глючит. Нет, спасибо.
Хороших вам Заказчиков!
А если серьезно, простите, не могу спокойно такое читать после постоянных битв с заказчиками, попытками вспомнить, почему так сделано, а не иначе, постоянным давлением от собственного начальства на нас разработчиков:
— Ну, заказчик позвонил и попросил…
— Пусть письменно подтвердит, поскольку это отменяет предыдущее требование.
и когда проект уже превращается в то, что у вас на картинке и все глючит. Нет, спасибо.
Хороших вам Заказчиков!
Мы четко определяем границу, где заканчиваются разумные требования и начинаются капризы. Капризы не реализуем никогда или только по большим праздникам.
Занимаясь «капризами» вы перестаете быть эффективным с точки зрения бизнеса заказчика. А это, рано или поздно, приведет вас к расторжению договорных обязательств.
Занимаясь «капризами» вы перестаете быть эффективным с точки зрения бизнеса заказчика. А это, рано или поздно, приведет вас к расторжению договорных обязательств.
Одному мне показалось, что это старые добрые списки use case или user stories?
Топикстартер, вы просто работает с гос. или полу-гос. компаниями, поэтому у вас все так. У меня все точно также: фиксируем с заказчиком проблему, которую надо решить (как решать и в каком это виде должно быть — никто не в курсе, разумеется), называю заказчику потолок цены, а потом — решаем-решаем-решаем (итерационно, как полагается — и вообще, agile лучшая методика для работы с гос.заказчиками)…
Но не нужно вводить других разработчиков в заблуждение — это работает далеко не со всеми клиентами. Гос. (или просто крупный корпоративный) заказчик понимает, что он ничего не понимает (даже если на словах говорит обратное), поэтому готов платить деньги за то, чтобы «ему сделали хорошо». В средних/мелких коммерческих организациях все думают, что замечательно знают рынок, пытаются в этой связи сэкономить деньги, и объяснить им в итоге, что «этот миллион вы платите именно за то, что не можете сейчас четко сказать, что вам нужно, вам это будем придумывать мы, а вы потом будете хмурить носик, просить переделать, и мы будем переделывать, и потом через десяток вариантов, наконец сделаем то, что вас устроит» — практически нереально. Вот и приходится — писать всякие дурацкие детальные ТЗ, делать по ним, потом ссориться с заказчиком, всеж таки переделывать и платит он в итоге ту же сумму, что заплатил бы если бы с самого начала согласился не тратить время на ТЗ. Короче, как и во многих других сферах жизни, ключевая проблема — в доверии. Гос.заказчик зачастую доверять вынужден, вот и согласен работать «без формальностей», что, казалось бы, удивительно и полностью противоречит его сути.
Но не нужно вводить других разработчиков в заблуждение — это работает далеко не со всеми клиентами. Гос. (или просто крупный корпоративный) заказчик понимает, что он ничего не понимает (даже если на словах говорит обратное), поэтому готов платить деньги за то, чтобы «ему сделали хорошо». В средних/мелких коммерческих организациях все думают, что замечательно знают рынок, пытаются в этой связи сэкономить деньги, и объяснить им в итоге, что «этот миллион вы платите именно за то, что не можете сейчас четко сказать, что вам нужно, вам это будем придумывать мы, а вы потом будете хмурить носик, просить переделать, и мы будем переделывать, и потом через десяток вариантов, наконец сделаем то, что вас устроит» — практически нереально. Вот и приходится — писать всякие дурацкие детальные ТЗ, делать по ним, потом ссориться с заказчиком, всеж таки переделывать и платит он в итоге ту же сумму, что заплатил бы если бы с самого начала согласился не тратить время на ТЗ. Короче, как и во многих других сферах жизни, ключевая проблема — в доверии. Гос.заказчик зачастую доверять вынужден, вот и согласен работать «без формальностей», что, казалось бы, удивительно и полностью противоречит его сути.
Всё верно — ТЗ составляется (за редчайшими исключениями) одним человеком, а по-идее должно описывать сразу несколько областей проф-разработки. Мало того, что оно непонятно, требует постоянной корректировки, и плохо воспринимается по объёму, так ещё и в 95% случаев не учитывать массу факторов.
У нас структура немного попроще. Есть идея, вдохновитель. Весь этот инспирейшен передаётся дизайнеру, программерам передаются основные задачи продукта, чтобы они начали приблизительную подготовку решений. Когда дизайн готов на треть, это передаётся верстальщику и программистам, для воплощения. Далее работа идёт практически одновременно с лёгким опережением по дизайну и чем ближе к завершению, тем этот разрыв более сокращается.
У нас структура немного попроще. Есть идея, вдохновитель. Весь этот инспирейшен передаётся дизайнеру, программерам передаются основные задачи продукта, чтобы они начали приблизительную подготовку решений. Когда дизайн готов на треть, это передаётся верстальщику и программистам, для воплощения. Далее работа идёт практически одновременно с лёгким опережением по дизайну и чем ближе к завершению, тем этот разрыв более сокращается.
Мы тоже не используем в своей работе над проектом ТЗ в классическом понимании.
Есть тактический план разработки на 6 месяцев, где тезисно указаны этапы разработки. И есть четкое формулирование задач по мере решения предыдущих.
Такой вариант наиболее гибкий, позволяет учитывать тенденции на рынке, вносить изменения при поступлении новой информации, не зависать на стратегическом планировании, которое все равно через полгода потребует корректировки.
Есть тактический план разработки на 6 месяцев, где тезисно указаны этапы разработки. И есть четкое формулирование задач по мере решения предыдущих.
Такой вариант наиболее гибкий, позволяет учитывать тенденции на рынке, вносить изменения при поступлении новой информации, не зависать на стратегическом планировании, которое все равно через полгода потребует корректировки.
У нас многостраничное ТЗ постепенно заменяется связкой: прототипы + описание логики работы системы + сценарии использования. Получается более наглядно и юзабельно для всех сторон. Позволяет запускать дизайн еще на стадии проектирования…
Расскажите пожалуйста, а как вы решили проблему с поддержкой разработанного функционала и передачей его в опытную эксплуатацию?
Я тоже люблю мини-ТЗ: конкретная небольшая проблема, описание предполагаемого решения, бюджетец и срок.
Позволяет часто радовать заказчика решением наиболее важных проблем и гибко менять требования по ходу развития системы.
Но часто бывает так, что заказчик хочет понять стоимость всей системы.
Тогда без полноценного ТЗ не обойтись, иначе как оценить то, что еще не формализовано?
Позволяет часто радовать заказчика решением наиболее важных проблем и гибко менять требования по ходу развития системы.
Но часто бывает так, что заказчик хочет понять стоимость всей системы.
Тогда без полноценного ТЗ не обойтись, иначе как оценить то, что еще не формализовано?
Вы сравнивали по стоимости ваш процесс с процессом с ТЗ?
Мне видится, что на работу без ТЗ требуется больше человеко-времени. Когда есть ТЗ, разработчики разрабатывают, тестировщики тестируют, тех. писатели описывают, причем сходу. А без ТЗ они все проделывают работу по составлению ТЗ для себя каждый раз. И менеджер работает больше.
Мне видится, что на работу без ТЗ требуется больше человеко-времени. Когда есть ТЗ, разработчики разрабатывают, тестировщики тестируют, тех. писатели описывают, причем сходу. А без ТЗ они все проделывают работу по составлению ТЗ для себя каждый раз. И менеджер работает больше.
Все смешали в кучу, а в результате получился ложный посыл.
То что вы описали к ТЗ имеет опосредованное отношение — это безнес-аналитика, организация бизнес-процессов и прочая галиматья, внешняя для проекта написания ПО, но входящая в решение проблемы заказчика.
ТЗ — он либо есть как документ, либо есть в голове вашего бизнес-аналитика или ПМ-а. Если команда и проект небольшой можно не формулировать ТЗ в документе, если носителя сокровенного знания не жалко. Лично мне в такой-же ситуации было просто некогда общаться по каждому пустяковому поводу и я писал и поддерживал документ — хорошо экономит время.
ТЗ — это не бумажка, а квинтэссенция знания о необходимом продукте. Хорошо когда есть понимание того что нужно — у заказчика или у исполнителя, но тогда нет проблем это понимание формализовать. А вот когда понимания нет, тогда приходиться изощряться — делать маленькие шажки что бы частично сформировать окружение в котором придет понимание конечного продукта или что-то рядом с этим.
То что вы описали к ТЗ имеет опосредованное отношение — это безнес-аналитика, организация бизнес-процессов и прочая галиматья, внешняя для проекта написания ПО, но входящая в решение проблемы заказчика.
ТЗ — он либо есть как документ, либо есть в голове вашего бизнес-аналитика или ПМ-а. Если команда и проект небольшой можно не формулировать ТЗ в документе, если носителя сокровенного знания не жалко. Лично мне в такой-же ситуации было просто некогда общаться по каждому пустяковому поводу и я писал и поддерживал документ — хорошо экономит время.
ТЗ — это не бумажка, а квинтэссенция знания о необходимом продукте. Хорошо когда есть понимание того что нужно — у заказчика или у исполнителя, но тогда нет проблем это понимание формализовать. А вот когда понимания нет, тогда приходиться изощряться — делать маленькие шажки что бы частично сформировать окружение в котором придет понимание конечного продукта или что-то рядом с этим.
:)
Квинтэссенцией знания является код. А бумажка устаревает уже на момент ее написания.
Носителями ТЗ является весь коллектив разработчиков.
Общение по «пустяковым» поводам — норма для XP.
Даже если у всех есть понимание о будущем продукте, у разработчиков и заказчика оно кардинально разное. И это ТЗ никогда не разрешит.
Квинтэссенцией знания является код. А бумажка устаревает уже на момент ее написания.
Носителями ТЗ является весь коллектив разработчиков.
Общение по «пустяковым» поводам — норма для XP.
Даже если у всех есть понимание о будущем продукте, у разработчиков и заказчика оно кардинально разное. И это ТЗ никогда не разрешит.
Ваше право куда тратить время, которое есть самый ценный ресурс в любом проекте. Если же команда общается по пустяковым поводам, то она не может быть носителем чего бы то ни было — на лицо множественные внутренние конфликты, требующие разрешения.
понимание не может быть разным, оно может быть верным и не верным. Если разработчики имеют отличное от заказчика представление, то это просто фейл.
ТЗ ничего не должен разрешать. Наборот — ТЗ, помимо прочего, результат работы по разрешению конфликтов.
И да, повторюсь, ТЗ — это не бумажка.
понимание не может быть разным, оно может быть верным и не верным. Если разработчики имеют отличное от заказчика представление, то это просто фейл.
ТЗ ничего не должен разрешать. Наборот — ТЗ, помимо прочего, результат работы по разрешению конфликтов.
И да, повторюсь, ТЗ — это не бумажка.
Самое смешное, мы всегда успеваем в срок и делаем даже больше, чем ожидает заказчик.
Я не зря взял слово «пустяки» в кавычки.
Конечно же на лицо множественные внутренние конфликты… :D Почитайте про методологию XP, там постоянные корректировки — обязательны в разработке. Иначе каждый наделает такого, что потом ни одно ТЗ не поможет.
В нашей работе нет конфликтов между заказчиком и разработчиком, между разработчиками, потому что все работают на единый результат.
Хотя, что я спорю, вы же лучше меня знаете как правильно все делать и использовать.
Я не зря взял слово «пустяки» в кавычки.
Конечно же на лицо множественные внутренние конфликты… :D Почитайте про методологию XP, там постоянные корректировки — обязательны в разработке. Иначе каждый наделает такого, что потом ни одно ТЗ не поможет.
В нашей работе нет конфликтов между заказчиком и разработчиком, между разработчиками, потому что все работают на единый результат.
Хотя, что я спорю, вы же лучше меня знаете как правильно все делать и использовать.
Как FPGA-разработчик могу с уверенностью сказть, что нельзя пускать составление ТЗ на самотек, нужно не забывать и свои интересы. Иной раз заказчик может просто «за компанию» включить не особо нужный ему пункт а количество работы от этого пункта увеличится ровно вдвое. Или наоборот сделать чрезмерное послабление, а потом жаловаться: «ой, а нам нужно побольше исправляющую способность… можно ещё добавить?».
Напишите в начале топика: мы маленькие и работаем по Agile в проекте, где денег куры не клюют.
Тогда всё остальное можно было бы опустить.
А так, в качестве контрагумента можно привести описание процесса разработки ПО для шаттла habrahabr.ru/blogs/development/116206/
Тогда всё остальное можно было бы опустить.
А так, в качестве контрагумента можно привести описание процесса разработки ПО для шаттла habrahabr.ru/blogs/development/116206/
Карта проблем конечно звучит красиво… Но как быть, когда заказчик смотрит на Вашу «карту проблем», и задает простой вопрос: «сколько это будет стоить и когда будет сделано»? Как Вы сами сможете, не имея техзадания, хотя бы приблизительно оценить объем предстоящих работ? Как будете озвучивать стоимость разработки, если не сможете рассказать заказчику, что конкретно Вы будете делать?
Но как быть если к тебе уже приходят с готовым ТЗ?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему мы никогда не составляем ТЗ. А что взамен?