ТЗ передать можно просто на бумажке, а можно с динамическим прототипом.
Умышленно не писала про прототипы, так как проблема единая.
Опять же — круто, когда ТЗ могут изменять (не забывая про пользователей), оперативно, не тратя лишнее время разработчиков.
К тому же, если в ТЗ прописать, где и как можно поменять интерфейс — получится гораздо легче вносить изменения ;)
Я не пишу о методологии, как таковой.
Пост о ТЗ на интерфейс, который будут разрабатывать после аутсорсинговых работ, то есть сильно потОм, и другие люди.
Я не застрагиваю тему, _как_ будут разрабатываться, тестироваться и доводиться до ума конечный продукт.
И, к сожалению, ни разу не сталкивалась с документом «Методика испытаний», поделитесь?
Чем больше детализация — тем больше шанс того, что ему будут бездумно следовать, исполняя каждую деталь.
Это риск для конечного пользователя (вдруг что-то можно сделать лучше, чем было на момент написания такого детального ТЗ).
Мне кажется, что идеального ТЗ на интерфейс «под всех» — не может существовать.
Клиентоориентированность, персональный подход делают ТЗ не просто формальным документом.
Зарубежом есть практика — публиковать требования к интерфейсам в общем доступе.
Не очень давно выкладывали существующие требования для разных платформ, в разрезе стран, можно погуглить.
Не стала писать «надо следовать», написала «желательно».
К сожалению, компании — «написатели» ТЗ не знаю ваш продукт лучше вас, согласитесь.
Делать просто потому, что так написано — печально, особенно, если повлиять на изменение Вы не в силах (к примеру, вы — разработка на аутсорсе, которой передали ТЗ). Мрак ;(
Предполагаю, проблема государственного сектора в том, что в договоре трудно установить нормальные условия (изменение требований, в частности) для исполнителя — из-за фиксированных форм и отчетности.
Ну и БЮРОКРАТИЯ, конечно же, куда без неё.
Кстати, проблема актуальна и для коммерческих фирм, которые отдают работы на сторону по тендерам.
amarao, спасибо за комментарий, действительно, ТЗ — не воспринимается как документ, которому желательно следовать.
Так как я не могу говорить за всех специалистов, которые занимаются написанием ТЗ для разработки, говорю про ТЗ на интерфейс системы (раньше ведь такого не было, и разработчики, по-большому счету, сами решали что и куда ставить и какие будут «рюшечки»).
Если все делается внутри компанией самостоятельно (полный цикл), всё просто: ставится и исполняется определенная задача, исходя из того «как это принято у нас».
Если кусок «аналитика+проектирование+дизайн» делает кто-то сторонний, убедить разработку в правильности решений исполнителя — очень сложно.
И плевать разработке на ТЗ (у них есть свое мнение), особенно если они _никак_ не принимали участие в проекте.
+1 — по поводу «проверить ТЗ» — это попахивает садизмом: "ПрокомментируйРаскритикуй же меня, разработка!".
А вообще (побуду немного девочкой), диагноз «В избранное» напоминает шопоголизм: покупаешь-покупаешь-покупаешь (читай — «сохраняешь в избранном»), а толку нет. Потому что _никогда_ не прочитаешь
: (
magicstyle,
спасибо за статью, очень вовремя нашла.
По опыту, подскажите, что посоветуете использовать (и методологию, и ПО), для описания одного участка бизнеса, а не всей структуры?
На участке: входящая-исходящая информация часто повторяется, отчетности нет, ролей 5-6.
theproof, зато есть хорошее настроение, полученное от общения — а это, по-моему, главное, что нужно получать от таких мероприятий.
Не было цели пойти на мероприятие, чтобы потом критиковать организаторов.
amarenkov, просто Вы просто не к тому HR'у и не к тем специалистам — на себе проверено, опробовано, удавлено.
Любовь к Яндексу ушла после того, как выкатили одно из обновлений, в котором присутствовала как идея, так и дословная формулировка из моего тестового задания.
Есть хорошие специалисты, которые с тобой беседуют — проверено. У них блеск в глазах и интерес к твоим стремлениям (как ни крути, в Яндекс идешь с благой целью — сделать Интернет лучше). Вот они тебя понимают и рады нанять.
А есть незаинтересованные: которым всё равно. На них нарваться хуже всего.
Мне с таким вот, незаинтересованным, пришлось столкнуться.
Теперь я просто наблюдатель со стороны, как делают интернет лучше.
Другие люди: (
Хочется, чтобы разработка принимала участие, от которого получится тот самый профит, на этапе создания ТЗ.
Мне снять розовые очки?)
Умышленно не писала про прототипы, так как проблема единая.
Опять же — круто, когда ТЗ могут изменять (не забывая про пользователей), оперативно, не тратя лишнее время разработчиков.
К тому же, если в ТЗ прописать, где и как можно поменять интерфейс — получится гораздо легче вносить изменения ;)
Пост о ТЗ на интерфейс, который будут разрабатывать после аутсорсинговых работ, то есть сильно потОм, и другие люди.
Я не застрагиваю тему, _как_ будут разрабатываться, тестироваться и доводиться до ума конечный продукт.
И, к сожалению, ни разу не сталкивалась с документом «Методика испытаний», поделитесь?
Это риск для конечного пользователя (вдруг что-то можно сделать лучше, чем было на момент написания такого детального ТЗ).
Клиентоориентированность, персональный подход делают ТЗ не просто формальным документом.
Зарубежом есть практика — публиковать требования к интерфейсам в общем доступе.
Не очень давно выкладывали существующие требования для разных платформ, в разрезе стран, можно погуглить.
К сожалению, компании — «написатели» ТЗ не знаю ваш продукт лучше вас, согласитесь.
Делать просто потому, что так написано — печально, особенно, если повлиять на изменение Вы не в силах (к примеру, вы — разработка на аутсорсе, которой передали ТЗ). Мрак ;(
Ну и БЮРОКРАТИЯ, конечно же, куда без неё.
Кстати, проблема актуальна и для коммерческих фирм, которые отдают работы на сторону по тендерам.
Так как я не могу говорить за всех специалистов, которые занимаются написанием ТЗ для разработки, говорю про ТЗ на интерфейс системы (раньше ведь такого не было, и разработчики, по-большому счету, сами решали что и куда ставить и какие будут «рюшечки»).
Если все делается внутри компанией самостоятельно (полный цикл), всё просто: ставится и исполняется определенная задача, исходя из того «как это принято у нас».
Если кусок «аналитика+проектирование+дизайн» делает кто-то сторонний, убедить разработку в правильности решений исполнителя — очень сложно.
И плевать разработке на ТЗ (у них есть свое мнение), особенно если они _никак_ не принимали участие в проекте.
+1 — по поводу «проверить ТЗ» — это попахивает садизмом: "
ПрокомментируйРаскритикуй же меня, разработка!".алкоголлюбитель добавлять в избранное.Спасибо, Dehumanizer, за пост — прямо в яблочко попал.
Волшебно: "«Рефреш», «рефреш», «рефреш»… Так до бесконечности (пока глаза сами не закроются и надо спать)" ©
А вообще (побуду немного девочкой), диагноз «В избранное» напоминает шопоголизм: покупаешь-покупаешь-покупаешь (читай — «сохраняешь в избранном»), а толку нет. Потому что _никогда_ не прочитаешь
: (
спасибо за статью, очень вовремя нашла.
По опыту, подскажите, что посоветуете использовать (и методологию, и ПО), для описания одного участка бизнеса, а не всей структуры?
На участке: входящая-исходящая информация часто повторяется, отчетности нет, ролей 5-6.
Не было цели пойти на мероприятие, чтобы потом критиковать организаторов.
Возможно, на Chaos Constructions будет лучше: )
[наивная, надеется]
В таком ключе все специалисты, которые не связаны с кодом — потенциальные перспективные кандидаты.
«Направленность креатива» — сильно: )
Любовь к Яндексу ушла после того, как выкатили одно из обновлений, в котором присутствовала как идея, так и дословная формулировка из моего тестового задания.
Есть хорошие специалисты, которые с тобой беседуют — проверено. У них блеск в глазах и интерес к твоим стремлениям (как ни крути, в Яндекс идешь с благой целью — сделать Интернет лучше). Вот они тебя понимают и рады нанять.
А есть незаинтересованные: которым всё равно. На них нарваться хуже всего.
Мне с таким вот, незаинтересованным, пришлось столкнуться.
Теперь я просто наблюдатель со стороны, как делают интернет лучше.
Другие люди: (
Кто-же именно зарегистрирован в Яндекс.Маркете?
Возможно, это будет не «средневзвешенная по больнице», а какой-то прогноз.
Очень интересно!
Непонятно, зачем спрятали.