Игорь Зильберг
По описанию требуемого опыта и компетенций в вакансии.
Часто использование грейда в вакансии, из-за нечеткости его определения в разных компаниях, приводит к неадекватному трактованию остального текста вакансии и, в итоге, малому количеству адекватных реальным требованиям откликов.
Сам офигел)
Ну, это немного передергивание:)
Статья про то, что "не надо считать что чем подробнее тем лучше". Разумеется, это не равно утверждению "чем меньше, тем лучше". Что-то действительно может требовать подробного и грамотного описания. Например, специфика предметной области, не доступная на уровне здравого смысла (или контринтуитивная).
Кстати, обычно, большинство людей чувствуют себя комфортнее как раз в определенности. И выезжают за счет того что "дык у вас в ТЗ так написано. А чего не написано - того нет". Неопределенность сложнее для обоих сторон и требует грамотной работы с ней. Но маскировка неопределенности фантазиями и глупостями (читай "плохо написанное ТЗ") - хуже чем "явная" неопределенность.
Ну, есть такой вариант ответа: исчерпывающее описание содержит код:) Если этот код хорошо структурирован, читаем, не содержит лишнего то он является максимально приближенным к реальности описанием того, как программа будет выполняться на процессоре.
Постановка задачи и описание результата ее выполнения - это очень разные вещи, которые описываются по-разному. К сожалению, часто их путают и считают, что ТЗ "описывает" разработанный продукт.
И заказчик и подрядчик птицы вольные и могут желать чего угодно. Но есть более продуктивные пути сотрудничества, а есть менее. К сожалению, детальное ТЗ часто не защищает клиента от риска "получить не то что нужно", а иногда еще и усиливает его (потому что подрядчик тоже будет думать не над тем, что нужно, а над тем чтобы соответствовать написанному в ТЗ).
"заказчику нужно определиться с бизнес-целями, а компания-разраб все сделает сама" - представьте, так бывает:) Если каждая из сторон грамотно сделала свою работу: заказчик не вываливал необоснованные фантазии или личные мотивы вместо бизнес-целей, а подрядчик имел достаточную компетенцию чтобы их понять и превратить в правильные функциональные требования и приоритеты.
Не могу согласиться с этим утверждением как с догмой:)
Многие прекрасные продукты разрабатываются без ТЗ или по очень высокоуровневым требованиям/целям (BRD, например). Никого уже не удивить гибкими процессами разработки, основанными на обратной связи от потребителей, результатах тестирования гипотез и т.п.
Да, если нет детальных требований то нельзя утверждать что-либо о соответствии продукта этим требованиям. Но это зачастую не нужно. Заказчику, заинтересованному в продукте, важно получить от этого продукта пользу для бизнеса (а может для себя лично или каких-то других стейкхолдеров).
Важно очень четко и прозрачно понимать кому и какую пользу должен принести продукт, а также иметь достаточные компетенцию и кругозор чтобы предложить оптимальный способ создания этой пользы. В таком случае, какой бы ни был результат, если он достигает цели - все будут довольны.
Это, конечно же, тоже не догма. Бывает, что детальное описание требований и сверхстрогая приемка необходимы для обеспечения высокого уровня надежности или безопасности. Но статья, с учетом уровня погружения, скорее про более простые случаи, где риск измеряется в относительно небольших суммах денег, и не грозит жизни и здоровью людей, например.
Да, рисунок забавный, но то что на нем изображено вполне серьезно и важно:) Можно нагуглить массу более формальных описаний и историю этого фреймворка.
"ПО для веба" может представлять собой баннер, а может систему управления логистикой глобальной корпорации. Комплексность этих задач отличается на много порядков. Соответственно и подходы для их решения надо выбирать разные. Не могу дать конкретных советов или ответов не понимая о каких задачах и каком процессе их реализации идет речь:)
Если у вас получается реализовывать ваши задачи в рамках достаточно строгого процесса то, вероятно, действительно имеет смысл подумать о стандартизации подхода к описанию требований чтобы делать это быстрее и с более предсказуемым качеством.
С вероятностью 99% все что мы придумываем - уже придумано до нас. Имеет смысл инвестировать какое-то время в то чтобы изучать чужой опыт и подходы, отраженные в "трудах":) Это может сильно сэкономить время и повысить уровень компетенции.
Какие стандарты?
Стандарты нужны для стандартизируемых процессов/продуктов.
Тут уместно посмотреть на CYNEFIN Framework.
Если мы работаем над задачами типа Simple, то действительно можно и нужно использовать готовые стандарты и делать как написано сильно не фантазируя. Если мы работаем над Complicated-задачами, то нам скорее нужны не стандарты (готовые решения/инструкции), а принципы, лучшие практики или эксперт, который скажет "как надо".
Ну и далее, по мере увеличения неопределенности цели и пути ее достижения, готовые решения, стандарты и практики работают все меньше.
Прелесть в том, что отнесение задачи к той или иной категории и выбор метода ее решения субъективно и основано на понимании задачи и предыдущем опыте. Таким образом, надо думать своей головой и выбирать решение (в т.ч. применение стандартов или готовых практик) под ситуацию.
Имеет смысл разрабатывать свой стандарт, если есть много типовых задач и нужно обеспечить их контролируемое выполнение "на потоке". Например, разработка лендингов или типовых корпоративных сайтов может делаться по "шаблону ТЗ", который лишь слегка модицифицируются под потребности заказчика. Но кажется невозможным использовать готовый шаблон для описания требований, например, к CRM или маркетплейсу.
И мне бы этого хотелось:)
К сожалению, не существует идеального образца или шаблона, по которому можно сделать все классно. Намеренно не привожу конкретные примеры реализации т.к. они создают искушение сделать также или скопировать, вместо того чтобы думать о принципах в контексте своей текущей задачи.
Короткий ответ — общаемся:)
Когда человек приходит в команду про него уже много чего известно после процесса отбора и найма. Как минимум, его руководителю.
После выхода на работу про человека узнают и другие - в приветственном письма, в общении внутри компании (компания ведь не большая).
При подключении человека к проекту имеет значение его опыт в контексте конкретной задачи. И когда к проекту подключается новый человек, разговор о соответствии его компетенций задаче и необходимой помощи должен состояться в любом случае, независимо от уровня и опыта этого человека.
Ну а через пару совместных проектов уже про всех все и так понятно:)
Наличие грейда в бейджике не устраняет необходимости общаться, скорее делает это общение более предвзятым, менее конструктивным или недостаточным.