Comments 101
По этому поводу есть характерный анекдот.
— Что надо сделать для того чтобы спутники успешно выходили на орбиту?
— Отправлять их туда вместе с их разработчиками.
С ними есть сложность: они как посмотрят на ТЗ, в котором есть мутные места, так сразу говорят: “Тут какой-то бред, я с таким не работаю!”
Хм, аналитик написал мутное ТЗ, но виноват разработчик? Интересно.
Я, как разработчик, не работаю с мутным ТЗ, потому что не понятно, что именно я должен сделать. Я понял написанное вот как-то так, аналитик имел в виду другое, а заказчик вообще хотел третье. Написано ТЗ непонятно, неоднозначно или неполно, я иду и пинаю аналитика, чтобы у меня было полное, ясное и однозначное ТЗ, это его работа в конце концов.
Может быть я работаю в какой-то особой конторе, но у нас если реализация отличается от описанного в ТЗ, то её просто не пропустит QA и отправит обратно на доработку.
Понимаю вас. При этом чем хорош случай с курсами, что там все однозначно. Нужно написать код, и получить совершенно однозначные результаты, которые либо проверят однокурсники, либо проверят парсеры.
Значит дело не всегда в мутных ТЗ?
Кстати про мутные ТЗ, я в позапрошлой статье тоже писал «ТЗ высокой четкости»
Значит дело не всегда в мутных ТЗ?
Кстати про мутные ТЗ, я в позапрошлой статье тоже писал «ТЗ высокой четкости»
Неясная ситуация
Есть ТЗ, есть несоответствие результата с ТЗ
Если оплата прошла — значит ТЗ было мутное или нужно не то, что в ТЗ, или оно вообще не нужно ТЗ(оно для проформы)
Какие еще варианты?
Я разработчик, и я с ТЗ не работаю. Вместо этого я работаю по постановкам, написанным аналитиками. И там зачастую написана какая-то хрень. Есть у нас пять аналитиков, которые умеют писать постановки, остальные пишут дикую хрень.
Когда мне прилетает слишком дикая постановка — я отказываюсь по ней работать пока ее не приведут в порядок (при поддержке начальника отдела и ведущих программистов), одного аналитика я так довел до слез. Но чаще бывает что постановка в целом понятная, но пара абзацев в ней — хрень. Или мне нужно исправить баг в программе, которую писал кто-то другой… по постановкам в которых была написана хрень.
И когда в такой постановке оказывается слишком много хрени, я ее начинаю пропускать и могу уже не заметить действительно важную информацию.
Разновидности хрени:
1. Код прямо в постановке
К примеру, однажды мне довелось чинить ETL-процедуры. На каждую из них была написана постановка, в которой был приведен код SQL-запроса который нужно было выполнить. И этот запрос на сотню строк работал неправильно: либо пропускал строки, либо дублировал их, либо просто выполнялся слишком долго. Ну и как его чинить-то когда он записан в требованиях?
И даже если опустить формальности — как понять что этот код должен был делать?
2. Ритуальные заклинания
Когда делается много типовых модулей — то программисты выносят повторяющиеся вещи в компоненты или подпрограммы. А в постановках аналитики обычно используют копи-паст. Подобные блоки скопированного текста превращаются в ритуальные заклинания, сопровождающие каждую новую постановку. И когда в очередной постановке эти заклинания оказываются чуть-чуть в другом порядке — никто этих изменений не замечает пока не прилетает блокер с прода.
3. Копи-паст внутри постановки
Допустим, есть объекты пяти разных типов, которые нужно обрабатывать одинаково, и еще один тип объектов с особой обработкой. Что делает аналитик? Он копирует описание первого типа объектов 4 раза, исправляя название.
А потом программисту надо в уме делать дедупликацию. Иногда получается неудачно.
Согласен, это все очень печально и приводит к ложной реализации. Стараюсь избегать такого в работе и даже писал уже в позапрошлой статье про «ТЗ высокой четкости» про примеры адовее ваших -)
При этом курсы хороши тем, что в курсах с ТЗ все в порядке. Они реализуемы и пропущены через многих разрабов, которые там повышали уже квалификацию.
При этом курсы хороши тем, что в курсах с ТЗ все в порядке. Они реализуемы и пропущены через многих разрабов, которые там повышали уже квалификацию.
UFO just landed and posted this here
ТЗ высокой чёткости требует высокого опыта разработки. Нельзя написать чёткое ТЗ на средний проект простому смертному и не забыть ничего. Я в разработке уже 15 лет и сколько бы не стралася довести ТЗ до идеала, всё равно есть просчёты с которые попросту не учёл. И это не связанно с тем, что мало опыта, просто на большенство клиентов не хочет платить за потраченное время на написание ТЗ, по этому пишется сокрашённая версия с десяток страниц и всё. А далее уже всё в процессе, ну всё самое важное и значимое естественно расписанно…
Скажу вам больше. На супер четкое ТЗ большого может жизни не хватить -) А может не хватить жизни на его прочтение.
С другой стороны, маленькие проекты, или маленькие этапы отлично документируются.
Однако, большие системы все равно приходится описывать, оценивать, проектировать. По возможности работоспособными -)
С другой стороны, маленькие проекты, или маленькие этапы отлично документируются.
Однако, большие системы все равно приходится описывать, оценивать, проектировать. По возможности работоспособными -)
Согласен полностью, что на большой проект не хватит жизни. Я говорю про маленькие и средние а у средних уже начинается конкретные запарки. Мы не в силах продумать все нюансы и многое вылазит только в процессе.
В 90% случаях я не получаю ТЗ от клиентов… мне говорят, что приблизительно им нужно.
Я пишу ТЗ на понятном языке для клиента, после спрашиваю, всё ли это? Если он говорит, да, вроде бы всё, я его предупреждаю о том, что если мы что-то забыли в ТЗ, то возможно это будет доработка сверху, всё зависит от сложности.
Пишу ТЗ для программистов, прохожу проект с главным программистом. Накидываем структуру базы и определяемся по цене.
После я подписываю договор с клиентом.
В 90% случаях я не получаю ТЗ от клиентов… мне говорят, что приблизительно им нужно.
Я пишу ТЗ на понятном языке для клиента, после спрашиваю, всё ли это? Если он говорит, да, вроде бы всё, я его предупреждаю о том, что если мы что-то забыли в ТЗ, то возможно это будет доработка сверху, всё зависит от сложности.
Пишу ТЗ для программистов, прохожу проект с главным программистом. Накидываем структуру базы и определяемся по цене.
После я подписываю договор с клиентом.
Как автор отметил — есть разработчики которые придираются к ТЗ, ибо в нем много темных мест и есть разработчики которые делают так как написано и как понятно им и не уделяют внимание каким то хитрым особенностям требований. Про первых все понятно — но как правило им говорят смирись и работай. Про вторых, вообще это стиль работы, делай что понятно, непонятное потом разберем. Как правило никто не хочет ждать пока разберутся с требованиями, простой работы программиста никому не нужен, плюс все равно хотят увидеть что получилось в первом приближении и доработать требования — поэтому всегда торопят, а потом создается приличный скоуп багов, и журят программистов что они все еще косячут. Да и к тому же любое требование может представить всегда в ином свете.
Поэтому, все гораздо проще — проблема именно в ТЗ, ибо оно не передает эту информацию для программиста в правильном ключе.
Поэтому, все гораздо проще — проблема именно в ТЗ, ибо оно не передает эту информацию для программиста в правильном ключе.
Когда мне не задают вопросы по ТЗ, я уже начинаю напрягаться. Обычно причина одна: «не читал». Так что, если придирается, значит читал, круто!
С другой стороны конечно нужно смериться и ехать. Максимальная детализация в обозримые горизонты времени даже по маленьким задачам не достижима обычно.
И все же, история с курсами отлично показывает, что проблема не всегда в ТЗ. Там-то ТЗ всегда однозначные! Их уже выполняли многие разрабы за несколько лет. Получали результаты, которые можно было на парсере проверить к примеру -)
С другой стороны конечно нужно смериться и ехать. Максимальная детализация в обозримые горизонты времени даже по маленьким задачам не достижима обычно.
И все же, история с курсами отлично показывает, что проблема не всегда в ТЗ. Там-то ТЗ всегда однозначные! Их уже выполняли многие разрабы за несколько лет. Получали результаты, которые можно было на парсере проверить к примеру -)
Сколько заданий вы проверили? Скольким различным учащимся они соответствуют? Сколько из них допускали приведенные ошибки?
По началу проверял по 10-12 на каждую тему, никак не могу поверить. Теперь устал, проверяю по 3 (это минимум для зачета) на каждую тему, все одно и то же. Причем люди разные всегда, т.к. я медленно учусь и отстаю, люди меняются за время пока я тему прохожу.
Последний раз проверил 3 задания и во всех были приведенные ошибки. В предыдущем курсе 80% где-то не ставили подписи к графикам. Специально исследования не проводил.
Конечно можно прямо взять и посчитать репрезентативную выборку, оценить ЦА, посчитать отклонения. Если бы хотел бы дисер про это писать — занялся бы. А так не достаточно энтузиазма -)
Последний раз проверил 3 задания и во всех были приведенные ошибки. В предыдущем курсе 80% где-то не ставили подписи к графикам. Специально исследования не проводил.
Конечно можно прямо взять и посчитать репрезентативную выборку, оценить ЦА, посчитать отклонения. Если бы хотел бы дисер про это писать — занялся бы. А так не достаточно энтузиазма -)
Тогда да, похоже на системное заболевание. А народ в основном с высшим или нет?
Там без высшего смысла нет, в первых же лекциях матричное исчисление, системы линейных уравнений, регрессия, центральная предельная теорема. Думаю, что ребята без высшего технического, ну хотя бы без первых 2-3 курсов срезались на первых же лекциях.
Ну я без высшего, но курс ODS в первой двадцатке закончил, затем окунулся в kaggle. Математика осваивается или самостоятельно или, к примеру, с онлайн курсами.
Мне поэтому не очень понятен ваш комментарий. Выпускник тех вуза может знать или не знать математику, чаще, наверное, знает, но correlation doesn't imply causation.
Есть самородки, не спорю. При этом одно дело вспоминать, и другое дело по сухому с нуля. Не каждому дано.
Если у вас дар, не стоит это экстраполировать на всех -)))
Если у вас дар, не стоит это экстраполировать на всех -)))
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
А мне кажется дело в культуре. Вот есть люди, которые и за деньги и без денег вовсе будут делать правильно. Просто потому, что они верят, что надо делать правильно.
А есть люди, которым сколько не плати, сколько не штрафуй — ничего не меняется, одно расстройство.
А есть люди, которым сколько не плати, сколько не штрафуй — ничего не меняется, одно расстройство.
UFO just landed and posted this here
За что разрабу платят, то он и делает.
Задача менеджера жестко пресекать подобное отношение к работе. Согласился работать — работай хорошо. Не устраивает зарплата — скажи. Всё равно не повышают — уходи.
UFO just landed and posted this here
Когда между работодателем и сотрудником отношения требуют столь подробного документального описания, когда для решения рабочих вопросов стороны апеллируют к пунктам трудового договора и должностных инструкций, на мой взгляд для обоих лучше расстаться.
UFO just landed and posted this here
Вопрос на самом деле отличный. редко кто его поднимает, просто за время ИС сотрудник обычно понимает чего от него ждут. Если есть ощущение что сотрудник и руководитель по-разному понимают что значит "хорошо работать", нужно сесть вдвоем, обсудить и согласовать тезисно, чтобы это было принято обеими сторонами. Можно зафиксировать протоколом.
Если договориться не удалось, можно попробовать апеллировать к вышестоящему руководству или расстаться. Как-то так.
UFO just landed and posted this here
Все зависит от размера бизнеса.
Если это энтерпрайз, там наврняка будут инструкции на все случаи жизни.
Маленькая компания — точно нет, и никто не скажет чего от сотрудника понадобится завтра.
Средние — где-то между этими крайностями. Если бизнес быстро растёт — в нём всё быстро меняется. В том числе меняются требования к сотрудникам.
Вопрос, в каком варианте конкретному человеку комфортнее. Я вот по себе знаю, что точно не хочу работать в компании где чётко прописаны инструкции на все случаи жизни. По мне лучше продуктивный хаос небольшой компании. Это интереснее.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Программисту платит работодатель а не заказчик. Заказчик может сегодня быть а завтра — нет, а зарплата остается. Поэтому работу программиста оценивает именно тот кто непосредственно платит ему деньги.
Кроме того, работа программиста как правило это лишь часть объема услуг, за который заказчик платит деньги.
UFO just landed and posted this here
В этом случае работодатель и есть заказчик для программиста с точки зрения программиста, в коммерческом смысле слова.
Да, приходилось работать в компаниях, где между программистом и тем кто ставит ему задачи отношения были в духе заказчик-исполнитель. Где-то само так случилось, где-то, представьте, насаждалось искусственно! Кончалось всё тупиком. В конце концов "Заказчик" топал ногами, кричал, ругался, требовал. "Исполнитель" отбивался пунктами ТЗ, инструкций и pocker-face'ом. При этом оба получали стабильную зарплату а проекты тем временем затягивались на годы.
UFO just landed and posted this here
UFO just landed and posted this here
Все верно, только есть ТК РФ, по которому ни уволить ни даже в деньгах прижать не получится без последствий. В нормальных коммерческих отношениях это рядовые инструменты взаимодействия заказчика с исполнителем.
UFO just landed and posted this here
Из своего опыта скажу, что на фрилансе и при работе с ИП такой проблемы с ТК РФ точно нет.
Таких — точно нет, но есть другие. Заказчику нужно больше работы за меньше денег, исполнителю — наоборот. Фундаментальная мотивация разная. От этого уже конкретные проблемы растут. Но это уже совсем другая история.
В голосовалке нужен еще вариант «Руководство не предоставляет ТЗ. Работаю на интуиции»
Я помню как-то давно обсуждал ТЗ с заказчиком по проекту. Обговорили функционал, описали в общих чертах. Потом я с командой обсудил, описал все технические моменты. В общем, все было весьма точно и без «тяп-ляп». Принес заказчику, он увидел, обрадовался. И я говорю:
— Ну что, подписываем и мы принимаемся за работу?
— Да, отлично! Если что-то еще изменится, я позвоню.
— Как изменится? Мы же уже ТЗ подписываем, на этом этапе уже ничего не должно меняться, будет реализовано как описано. Если вдруг что-то нужно будет, то мы готовы по доп. соглашению отдельно потом реализовать.
— Т.е. за дополнительные деньги?
— Конечно. Текущая стоимость покрывает только то, что описано в ТЗ.
— А вдруг я что-то упустил или мне надо будет что-нибудь поменять?
— Так для этого вы же и брали время на изучение ТЗ.
— Ну, я его изучал, но не с этой стороны. Там все, как-то, слишком досконально, я не вчитывался так глубоко. Может мы более общие моменты утвердим, чтобы, так сказать, иметь свободу в деталях?
С тех пор, сколько я ни смотрю на ТЗ, понимаю, что большинство, с обоих сторон, умышленно оставляют себе «свободу в деталях». И в ТЗ смотрят, когда либо проект очень большой и ответственный, либо хотят «продавить» контрагента.
— Ну что, подписываем и мы принимаемся за работу?
— Да, отлично! Если что-то еще изменится, я позвоню.
— Как изменится? Мы же уже ТЗ подписываем, на этом этапе уже ничего не должно меняться, будет реализовано как описано. Если вдруг что-то нужно будет, то мы готовы по доп. соглашению отдельно потом реализовать.
— Т.е. за дополнительные деньги?
— Конечно. Текущая стоимость покрывает только то, что описано в ТЗ.
— А вдруг я что-то упустил или мне надо будет что-нибудь поменять?
— Так для этого вы же и брали время на изучение ТЗ.
— Ну, я его изучал, но не с этой стороны. Там все, как-то, слишком досконально, я не вчитывался так глубоко. Может мы более общие моменты утвердим, чтобы, так сказать, иметь свободу в деталях?
С тех пор, сколько я ни смотрю на ТЗ, понимаю, что большинство, с обоих сторон, умышленно оставляют себе «свободу в деталях». И в ТЗ смотрят, когда либо проект очень большой и ответственный, либо хотят «продавить» контрагента.
У меня противоположенная проблема. Задача пришла в разработку, а потом все начинают менять ее. Тестировщику что-то не понравилось, он пошел обсуждать с менеджером, еще может влезть в спор пыха-разработчик. Дизайнер уступает и соглашается на изменения.
Посмотрело начальство, еще что-то велело поменять, и задача на выходе совсем не похожа на свое описание. Я стала говорить, что все желающие могут посмотреть макеты и высказаться дизайнеру, что их не устраивает, а если они этого не сделали, то их проблема, после отправки на тестирование ни какие изменения вне рамок макетов вноситься не будут. Что еще можно сделать?
Посмотрело начальство, еще что-то велело поменять, и задача на выходе совсем не похожа на свое описание. Я стала говорить, что все желающие могут посмотреть макеты и высказаться дизайнеру, что их не устраивает, а если они этого не сделали, то их проблема, после отправки на тестирование ни какие изменения вне рамок макетов вноситься не будут. Что еще можно сделать?
Ходить по воде и разрабатывать программы согласно ТЗ очень просто, если они заморожены (с) E. Berard
Все-таки «все желающие» могут затянуть создание даже самого простого макета на годы. Нужно договориться, чтобы утверждением макета занимался один единственный человек.
Тогда можно записывать пакет правок, которые этот человек согласует в работу.
Это может быть: артдир, менеджер проекта, аккаунт и т.д., как договоритесь.
Если дизайнер будет ходить и собирать правки со всех, то когда же он будет рисовать? -)))
Тогда можно записывать пакет правок, которые этот человек согласует в работу.
Это может быть: артдир, менеджер проекта, аккаунт и т.д., как договоритесь.
Если дизайнер будет ходить и собирать правки со всех, то когда же он будет рисовать? -)))
Ах, если бы у нас за год сменилось порядка 6 менеджеров. Нежные они какие-то.
Приоритеты меняются чуть ли не каждые два дня.
Приоритеты меняются чуть ли не каждые два дня.
И как вам удается вообще как-то работать?
Ну разве что воспринимать промежутки между сменой власти как спринты -)
Ну разве что воспринимать промежутки между сменой власти как спринты -)
Да вот по ходу предпоследнего я напугала. Все было норм, я возлагала большие надежды на девушку, она отработала полторы недели у нас и добралась побеседовать со мной. Я рассказала о проблемах, в основном про приоритетность задач, что все хотят свои задачи и срочно.
Пыха-программисты сделали какие-то своих задачи и требуют, что бы я дописала для них фронт, тестировщик что-то нашел и это тоже надо срочно фиксить. У маркетологов через три дня акция стартует, а у нас еще конь не валялся, начальство вообще хочет совсем другие задачи и тд и тд. Вот ей требовалось выслушать весь этот поток страждущих, разобраться, что действительно важно и скомандовать нам какие задачи, когда делаем, а какие пока откладываем. Там еще ряд моментов. Через пол часа узнали, что она решила уволиться.
Как работаем, ближе всего кан бан. Есть набор задач, выполняем из него, если что-то долгое, то делаем от нескольких дней или до нескольких недель, разбавляя процесс мелочовкой, занимающей от силы часик, полтора в день. Потом тестирование, еще ввели дизайнерскую приемку, они прямо в задачах подписывают, что принимают. Просто пищали, что не по макетам и жаловались начальству, что боятся ко мне подходить(сомнительное карьерное достижение, конечно).
Вообще мне нравится, что они принимают, порой глаз замылился, а они сразу видят, где отступ не совпадет или значок ниже, чем другие.
Еще случаются дни мелких задач, делаю дня два задач по 7-10 в каждый.
Пыха-программисты сделали какие-то своих задачи и требуют, что бы я дописала для них фронт, тестировщик что-то нашел и это тоже надо срочно фиксить. У маркетологов через три дня акция стартует, а у нас еще конь не валялся, начальство вообще хочет совсем другие задачи и тд и тд. Вот ей требовалось выслушать весь этот поток страждущих, разобраться, что действительно важно и скомандовать нам какие задачи, когда делаем, а какие пока откладываем. Там еще ряд моментов. Через пол часа узнали, что она решила уволиться.
Как работаем, ближе всего кан бан. Есть набор задач, выполняем из него, если что-то долгое, то делаем от нескольких дней или до нескольких недель, разбавляя процесс мелочовкой, занимающей от силы часик, полтора в день. Потом тестирование, еще ввели дизайнерскую приемку, они прямо в задачах подписывают, что принимают. Просто пищали, что не по макетам и жаловались начальству, что боятся ко мне подходить(сомнительное карьерное достижение, конечно).
Вообще мне нравится, что они принимают, порой глаз замылился, а они сразу видят, где отступ не совпадет или значок ниже, чем другие.
Еще случаются дни мелких задач, делаю дня два задач по 7-10 в каждый.
Во-первых точно фиксировать в ТЗ изменения (всегда иметь актуальную версию того, что реально делают/сделали) + вести историю изменений(кто, на каком этапе, что и почему изменил) + вести трассировку с другими требованиями + следить за трудозатратами. Требования в целом вещь живая…
Разумеется меняем ТЗ если изменения разумны и состав менеджеров/клиентов это не вгонит в депрессию. Изменения согласуем с участниками, оглядываясь на трудозатраты и текущие правила игры.
И я вообще не верю, что в средней/большой задаче нужно прям 100% всего разжевать, это может быть не рационально по времени. В процессе реализации задачи на языке программирования в конкретном проекте всегда имеют место быть нюансы, которые «дешевле» бывает подогнать на месте глядя в текущий код. Разумеется речь не о фатальных промахах ;)
Разумеется меняем ТЗ если изменения разумны и состав менеджеров/клиентов это не вгонит в депрессию. Изменения согласуем с участниками, оглядываясь на трудозатраты и текущие правила игры.
И я вообще не верю, что в средней/большой задаче нужно прям 100% всего разжевать, это может быть не рационально по времени. В процессе реализации задачи на языке программирования в конкретном проекте всегда имеют место быть нюансы, которые «дешевле» бывает подогнать на месте глядя в текущий код. Разумеется речь не о фатальных промахах ;)
4 года я был аналитиком и руководителем проектов.
И я считал свои ТЗ отличными и понятными. Я правда над этим много работал. Например, мне однажды попадалась подробная анкета на верстку от топового фрилансера на fl.ru, с 500+ положительными отзывами. Анкета состояла из 30+ пунктов поверх очень хороших макетов. Я из нее взял пунктов 10, и стал использовать на всех этапах, от ТЗ до приемки.
Но только став разработчиком, я понял, что все мои ТЗ были говно
Не в том плане, что неправильные. Просто не до конца проработанные. Конечно я и с ними добивался поставленных целей, но благодаря тому, что и дизайнеры и разработчики на своих этапах превносили в работу огромное количество полезных уточнений.
Например в ТЗ есть форма регистрации на 5 полей
99% ТЗ содержат перечень полей:
*Имя
*Email
День рождения
Телефон
Комментарий
Город
И поставив звездочки около имени и email заказчик, считает, что уже достаточно описал форму. И если есть moqups или дизайн формы — то вообще какие тут могут быть еще вопросы. А так как в его «сайте/портале/CRM/ERP...» таких форм десятки, а страниц десятки типов, то ТЗ уже и так на 50-100 страниц. А значит достаточно подробное)
Что же мы забыли
99% заказчиков и 95% аналитиков неспособны на таком уровне проработать ТЗ
Заказчики не могут, потому что не понимают уровень детализации, и у них нет времени, а аналитики, потому что чаще всего это просто вчерашние секретари/секретарши, помощники/помощницы. Которые внезапно для себя делают сайт/портал и теперь пишут к нему ТЗ. Как умеют.
Какие из всего этого я сделал выводы для себя?
Неважно какую роль я играю: аналитик, заказчик, программист, руководитель проекта — если я вижу, что ТЗ содержит тонны подводных камней, я сажусь и вместе в диалоге его прорабатываю. Как с тем, кто является для меня заказчиком, так и с тем, кто является для меня исполнителем.
Нет никакого смысла отправлять заказчика доделывать ТЗ, со словами «ТЗ мутное». Он не будет его доделывать, а просто найдет того, кто будет с таким работать. Наступит на все грабли, и справедливо будет считать всех программистов козлами. А ведь у него был шанс, поработать с хорошим программистом, который поможет сделать ТЗ не мутным.
Также нет никакого смысла отдавать все на откуп разработчикам с мыслями: «Форма регистрации, табличка отзывов, страница профиля — это же так стандартно. Что тут может быть непонятно.» Разработчик в 99% сделает как он делал в прошлом проекте, или как принято в его стеке технологий, или как ему проще и нравится. Его «нравится» редко когда совпадает с чувством прекрасного у заказчика.
И нет никакого смысла вылизать сразу все ТЗ на 3ё500 страниц.
Мой рецепт:
А еще очень важен постоянный диалог в стиле:
«Мы разбили проект/задачу на 7 частей. Первая часть займет неделю. Мы подготовили вопросы по ней. Сейчас проговорим детали.… (после того, как проговорили детали) Дня через три мы придем с новой порцией вопросов по первой части. А в начале следующей недели так же будем прорабатывать часть 2, подготовьте свои соображения, мы подготовим наши вопросы». И опять же это касается любого участника процесса: как заказчика, так и руководителя проекта, и тимлида, и разработчика, и дизайнера, и даже верстальщика.
Известно, что энтропия (в данном случае мера бардака в проекте) сама увеличивается, если не прикладывать осознанных усилий к её уменьшению. Так что помогают только осознанные усилия, диалоги, контроль, согласования, умелое отстаивание уже утвержденного, выкидывание лишнего. И только, если все это для уменьшения энтропии, а не снятия отвественности и оставления для себя свободы деталий и вариантов «нагнуть другую сторону»
И я считал свои ТЗ отличными и понятными. Я правда над этим много работал. Например, мне однажды попадалась подробная анкета на верстку от топового фрилансера на fl.ru, с 500+ положительными отзывами. Анкета состояла из 30+ пунктов поверх очень хороших макетов. Я из нее взял пунктов 10, и стал использовать на всех этапах, от ТЗ до приемки.
Но только став разработчиком, я понял, что все мои ТЗ были говно
Не в том плане, что неправильные. Просто не до конца проработанные. Конечно я и с ними добивался поставленных целей, но благодаря тому, что и дизайнеры и разработчики на своих этапах превносили в работу огромное количество полезных уточнений.
Например в ТЗ есть форма регистрации на 5 полей
99% ТЗ содержат перечень полей:
*Имя
День рождения
Телефон
Комментарий
Город
И поставив звездочки около имени и email заказчик, считает, что уже достаточно описал форму. И если есть moqups или дизайн формы — то вообще какие тут могут быть еще вопросы. А так как в его «сайте/портале/CRM/ERP...» таких форм десятки, а страниц десятки типов, то ТЗ уже и так на 50-100 страниц. А значит достаточно подробное)
Что же мы забыли
- Валидации полей на типы
- Валидации полей на лимиты (вряд ли 1800 год рождения — нормально)
- Валидации полей на уникальность (ну это же очевидно)
- Где проходит эта самая валидация(на сервере, или в браузере; понятно, что уникальность email мы не можем проверить в браузере, а вот желание проверять валидность и обязательность полей в браузере хорошо бы указать)
- Ошибки валидации (и даже если попросить их указать, вряд ли вы увидите две разные ошибки на невалидный email и уже существующий)
- А еще мы забыли уведомления на email, подтверждения телефона, восстановление пароля, авторизацию через соцсети и т.д. И каждый из этих пунктов — это формы, валидации, проверки, тексты ошибок, редиректы после успеха и неуспеха
- А еще самый коварный вопрос: при авторизации через соцсети, если пользователя с таким email нет, то отказывать в авторизации или создавать нового пользователя? А письмо ему на email в этом случае надо отправлять или нет?
99% заказчиков и 95% аналитиков неспособны на таком уровне проработать ТЗ
Заказчики не могут, потому что не понимают уровень детализации, и у них нет времени, а аналитики, потому что чаще всего это просто вчерашние секретари/секретарши, помощники/помощницы. Которые внезапно для себя делают сайт/портал и теперь пишут к нему ТЗ. Как умеют.
Какие из всего этого я сделал выводы для себя?
Неважно какую роль я играю: аналитик, заказчик, программист, руководитель проекта — если я вижу, что ТЗ содержит тонны подводных камней, я сажусь и вместе в диалоге его прорабатываю. Как с тем, кто является для меня заказчиком, так и с тем, кто является для меня исполнителем.
Нет никакого смысла отправлять заказчика доделывать ТЗ, со словами «ТЗ мутное». Он не будет его доделывать, а просто найдет того, кто будет с таким работать. Наступит на все грабли, и справедливо будет считать всех программистов козлами. А ведь у него был шанс, поработать с хорошим программистом, который поможет сделать ТЗ не мутным.
Также нет никакого смысла отдавать все на откуп разработчикам с мыслями: «Форма регистрации, табличка отзывов, страница профиля — это же так стандартно. Что тут может быть непонятно.» Разработчик в 99% сделает как он делал в прошлом проекте, или как принято в его стеке технологий, или как ему проще и нравится. Его «нравится» редко когда совпадает с чувством прекрасного у заказчика.
И нет никакого смысла вылизать сразу все ТЗ на 3ё500 страниц.
Мой рецепт:
- Разбить проекты на части
- Выбрать 1 часть. В начале желательно важную для проекта
- Детально описать
- Сделать 50%. Задать появившиеся вопросы
- Доделать, показать, получить правки, доделать
- Взять следующую часть
А еще очень важен постоянный диалог в стиле:
«Мы разбили проект/задачу на 7 частей. Первая часть займет неделю. Мы подготовили вопросы по ней. Сейчас проговорим детали.… (после того, как проговорили детали) Дня через три мы придем с новой порцией вопросов по первой части. А в начале следующей недели так же будем прорабатывать часть 2, подготовьте свои соображения, мы подготовим наши вопросы». И опять же это касается любого участника процесса: как заказчика, так и руководителя проекта, и тимлида, и разработчика, и дизайнера, и даже верстальщика.
Известно, что энтропия (в данном случае мера бардака в проекте) сама увеличивается, если не прикладывать осознанных усилий к её уменьшению. Так что помогают только осознанные усилия, диалоги, контроль, согласования, умелое отстаивание уже утвержденного, выкидывание лишнего. И только, если все это для уменьшения энтропии, а не снятия отвественности и оставления для себя свободы деталий и вариантов «нагнуть другую сторону»
У большинства ТЗ которые я видел есть одна или несколько из следующих проблем, из-за которых ими тяжело пользоваться:
1. Они слишком высокоуровневы и абстрактны, не учитывают многих деталей
2. Они плохо структурированы и их сложно читать
3. Они быстро устаревают и никто не заморачивается их обновлять (ни разработчик, ни аналитик)
Как я обычно работаю с ТЗ:
1. Читаю 1 раз (иногда по диагонали), чтобы понять что от меня хотят
2. Расписываю ТЗ в виде списка TODO задач с объёмом выполнения 0.5-1 день насколько это возможно. Обычно на данном этапе всплывает много непонятностей и неучтённых деталей, а также ограничений технологий
3. Разбираю все непонятности с аналитиком и дополняю свой TODO лист
4. Реализую по списку (позволяет не пропустить мелочей)
5. В ходе тестирования опять обсуждаем детали с тестировщиком и аналитиком.
Как решить проблемы ТЗ:
1. Аналитик должен «владеть» ТЗ. Т.е. поддерживать его в актуальном состоянии. Из этого следует, что аналитик всегда должен быть в курсе изменений
2. Для разработчика ТЗ более удобен не в виде формального документа, а в виде списка задач в таблице
3. Аналитик должен проводить подобие UAT после окончания разработки, чтобы убедиться что сделали то, что хотел заказчик.
4. Тестировщик с аналитиком пишут чёткие сценарии тестирования (желательно ещё до начала разработки)
1. Они слишком высокоуровневы и абстрактны, не учитывают многих деталей
2. Они плохо структурированы и их сложно читать
3. Они быстро устаревают и никто не заморачивается их обновлять (ни разработчик, ни аналитик)
Как я обычно работаю с ТЗ:
1. Читаю 1 раз (иногда по диагонали), чтобы понять что от меня хотят
2. Расписываю ТЗ в виде списка TODO задач с объёмом выполнения 0.5-1 день насколько это возможно. Обычно на данном этапе всплывает много непонятностей и неучтённых деталей, а также ограничений технологий
3. Разбираю все непонятности с аналитиком и дополняю свой TODO лист
4. Реализую по списку (позволяет не пропустить мелочей)
5. В ходе тестирования опять обсуждаем детали с тестировщиком и аналитиком.
Как решить проблемы ТЗ:
1. Аналитик должен «владеть» ТЗ. Т.е. поддерживать его в актуальном состоянии. Из этого следует, что аналитик всегда должен быть в курсе изменений
2. Для разработчика ТЗ более удобен не в виде формального документа, а в виде списка задач в таблице
3. Аналитик должен проводить подобие UAT после окончания разработки, чтобы убедиться что сделали то, что хотел заказчик.
4. Тестировщик с аналитиком пишут чёткие сценарии тестирования (желательно ещё до начала разработки)
А где же вариант «Пишу ТЗ»?)
Уже 5+ лет занимаюсь работой аналитика. Поработал с разработчиками от разных «полюсов»: как с теми, которые будут докапываться до каждой фразы, причём не стесняясь в выражениях и зачастую с большой долей высокомерия, так и с теми, которым ТЗ не нужен — достаточно постановки и времени на обсуждение.
Особая острота к работе добавляется, когда у тебя есть определённые компетенции в разработке, особенно в используемом в работе стеке. Как экстремальная форма ситуации — когда разработчики настолько плохи, что даже ты со своими «домашними проектами» их превосходишь в их области (при аутсорсе встречались такие). С одной стороны это огромный плюс — ты способен оценить сложность реализации того, что ты описываешь, ещё до оценки разработчиками, ты знаешь какие вещи реализуемы, какие сложнореализуемы, а какие просто невозможны, ты знаешь, где что-то может пойти не так и где требуется уточнение поведения. С другой стороны, ты «всего лишь» аналитик — большинство разработчиков встретит вторжение в сферу своей ответственности от тебя со скепсисом (осторожностью/враждебностью/возмущением). В итоге приходится постоянно лавировать между «тем, что ты знаешь» и «тем, что от тебя ждут», зарабатывать доверие разработчиков и бороться с внутренним конфликтом «брошу всё уйду в разработчики». К сожалению, это очень распространённая проблема разработчиков — недоверие к опыту не-разработчиков. Впрочем, объяснимая — аналитиков, которые пишут совершенно поверхностные ТЗ очень много.
Для себя я решил, что идеальная работа — это работа с командой, которая прежде всего всегда готова к обсуждению и готова к свободе своих действий в обмен на риск что-то выбросить и переписать. Можно называть это agile, можно lean, можно даже «пиши код бл*ть» — в любом случае нужно принять возникновение ошибок как что-то неотвратимое и постараться сэкономить время на попытках их предотвратить, потратив это время на создание функциональности. Ну, и мотивация всех на конечный результат, а не закрытие тасков в трекере. Пусть даже внутренняя.
Особая острота к работе добавляется, когда у тебя есть определённые компетенции в разработке, особенно в используемом в работе стеке. Как экстремальная форма ситуации — когда разработчики настолько плохи, что даже ты со своими «домашними проектами» их превосходишь в их области (при аутсорсе встречались такие). С одной стороны это огромный плюс — ты способен оценить сложность реализации того, что ты описываешь, ещё до оценки разработчиками, ты знаешь какие вещи реализуемы, какие сложнореализуемы, а какие просто невозможны, ты знаешь, где что-то может пойти не так и где требуется уточнение поведения. С другой стороны, ты «всего лишь» аналитик — большинство разработчиков встретит вторжение в сферу своей ответственности от тебя со скепсисом (осторожностью/враждебностью/возмущением). В итоге приходится постоянно лавировать между «тем, что ты знаешь» и «тем, что от тебя ждут», зарабатывать доверие разработчиков и бороться с внутренним конфликтом «брошу всё уйду в разработчики». К сожалению, это очень распространённая проблема разработчиков — недоверие к опыту не-разработчиков. Впрочем, объяснимая — аналитиков, которые пишут совершенно поверхностные ТЗ очень много.
Для себя я решил, что идеальная работа — это работа с командой, которая прежде всего всегда готова к обсуждению и готова к свободе своих действий в обмен на риск что-то выбросить и переписать. Можно называть это agile, можно lean, можно даже «пиши код бл*ть» — в любом случае нужно принять возникновение ошибок как что-то неотвратимое и постараться сэкономить время на попытках их предотвратить, потратив это время на создание функциональности. Ну, и мотивация всех на конечный результат, а не закрытие тасков в трекере. Пусть даже внутренняя.
Может быть не так уж и нужно это самое соответствие ТЗ. Часто бывает так, что к моменту когда ТЗ дописано — оно уже устаревает. Да что там ТЗ, даже просто требования. Ну сделали вы все строго по ТЗ, а клиенту продукт в том виде в котором он был актуален ранее — уже не подходит. В конечном итоге задача у вас и у клиента заработать денег, а не заниматься крючкотворчеством.
Мой свой вариант: пишу ТЗ, которые никто не читает. Даже заказчик.
Надо попробовать оформлять сценарии юзкейсов в виде комиксов. И чтобы в последнем кадре персонаж направлял вопросительный взгляд на читающего.
Надо попробовать оформлять сценарии юзкейсов в виде комиксов. И чтобы в последнем кадре персонаж направлял вопросительный взгляд на читающего.
Эм… тесты? Написал тесты, прогоняешь код. Если ТЗ неалгоритмизируемо или его трудно проверить — надо менять ТЗ, точнее, переформулировать так, чтобы можно было.
Из чеклиста в ТЗ:
n: Должны быть подписи осей на всех графиках.
Тест: Есть подписи или нет?
n: Должны быть подписи осей на всех графиках.
Тест: Есть подписи или нет?
(опуская детали реализации):
Это требует графика в машиночитаемом формате, разумеется, и соблюдения конвенций по именованию объектов в svg.
Именно это я и называю «менять ТЗ».
Вместо «должны быть подписи на графиках» — график должен быть в формате svg, в объекте g в объекте plot, для которого должны быть заданы объекты axis_x для горизонтальной оси и axis_y для вертиальной. Обе оси должны иметь текстовое описание в поле text соответствующего объекта axis_*.
Хорошо написанное ТЗ — половина теста. Хорошо написанный тест — половина программы.
Вот так вот написав 25% программы можно более-менее быть уверенным что программа на 100% хороша.
def test_plot_signature_x(...):
graph = fixture_to_create_graph()
assert len(graph.g.plot.axis_x.text) > 0
def test_plot_signature_y(...):
graph = fixture_to_create_graph()
assert len(graph.g.plot.axis_y.text) > 0
Это требует графика в машиночитаемом формате, разумеется, и соблюдения конвенций по именованию объектов в svg.
Именно это я и называю «менять ТЗ».
Вместо «должны быть подписи на графиках» — график должен быть в формате svg, в объекте g в объекте plot, для которого должны быть заданы объекты axis_x для горизонтальной оси и axis_y для вертиальной. Обе оси должны иметь текстовое описание в поле text соответствующего объекта axis_*.
Хорошо написанное ТЗ — половина теста. Хорошо написанный тест — половина программы.
Вот так вот написав 25% программы можно более-менее быть уверенным что программа на 100% хороша.
Многие разработчики когда-то прорешивали SICP и занимались собственными проектами, вылизывая их.
А потом пошли работать, и поняли, что платят — за говнокод, главное чтобы его было побольше и в срок. И еще — нужно свалить с проекта раньше, чем он начнёт реально использоваться.
Сначала человек читает Рихтера, у которого всё написано по делу. Потом сталкивается с чьими-то хотелками, пожеланиями людей, которые не в состоянии выражовывать свои мысли в письменном виде, но почему-то имеют и аттестат, и диплом, и даже деньги. Разумеется, половину того, что эти люди выражают, приходится отфильтровывать. А если не фильтровать — за это больше не заплатят, но сил останется меньше, чем у бодро кидающих лопатой говнокод и хорошо социализированных коллег.
А потом пошли работать, и поняли, что платят — за говнокод, главное чтобы его было побольше и в срок. И еще — нужно свалить с проекта раньше, чем он начнёт реально использоваться.
Сначала человек читает Рихтера, у которого всё написано по делу. Потом сталкивается с чьими-то хотелками, пожеланиями людей, которые не в состоянии выражовывать свои мысли в письменном виде, но почему-то имеют и аттестат, и диплом, и даже деньги. Разумеется, половину того, что эти люди выражают, приходится отфильтровывать. А если не фильтровать — за это больше не заплатят, но сил останется меньше, чем у бодро кидающих лопатой говнокод и хорошо социализированных коллег.
UFO just landed and posted this here
Если заказчик любимый — делаем то, что ему нужно.
Если заказчик нормальный — делаем то, что он хочет.
А если заказчик мерзкий — делаем то, что он написал в ТЗ.
Был случай год назад — сделали по ТЗ. Написано «web-технологии» — ставим клиента на web-технологиях. Ну и что, что он readonly, ввод из клиента в ТЗ не прописан. Ну значит данные вводятся с сервера, с клиента — только наблюдение за процессом.
Выяснилось это все на этапе пусконаладки за 3 дня до сдачи испытаний. В медвежьем углу Волго-Балта. Мда, настолько багрового клиента я ещё никогда не видел. Нам повезло — инфаркта у клиента не было.
Да, баг не наш — мы просто сделали по ТЗ. Но все равно — дичайший ляп. Пришлось сдавать через RDP, а потом переделывать.
Таких историй довольно много. Ибо ТЗ не застрахован от багов.
Вся беда в том, что ТЗ надо тестировать. Но заметить ошибку на этапе ТЗ — сложнее, чем на этапе отладки. И написание и тестирование ТЗ требует высокой квалификации.
Так что исправлять баги на отладке — дорого, а добиваться качественного ТЗ тоже дорого.
Если заказчик нормальный — делаем то, что он хочет.
А если заказчик мерзкий — делаем то, что он написал в ТЗ.
Был случай год назад — сделали по ТЗ. Написано «web-технологии» — ставим клиента на web-технологиях. Ну и что, что он readonly, ввод из клиента в ТЗ не прописан. Ну значит данные вводятся с сервера, с клиента — только наблюдение за процессом.
Выяснилось это все на этапе пусконаладки за 3 дня до сдачи испытаний. В медвежьем углу Волго-Балта. Мда, настолько багрового клиента я ещё никогда не видел. Нам повезло — инфаркта у клиента не было.
Да, баг не наш — мы просто сделали по ТЗ. Но все равно — дичайший ляп. Пришлось сдавать через RDP, а потом переделывать.
Таких историй довольно много. Ибо ТЗ не застрахован от багов.
Вся беда в том, что ТЗ надо тестировать. Но заметить ошибку на этапе ТЗ — сложнее, чем на этапе отладки. И написание и тестирование ТЗ требует высокой квалификации.
Так что исправлять баги на отладке — дорого, а добиваться качественного ТЗ тоже дорого.
Ну в общем см. рис 1
Да это очень важный момент. Когда вы получили подписанное ТЗ, а в нем чушь, если сделать чушь, то заказчик считает, что виноваты все равно вы. Ну не всякий конечно так считает, но часто, да.
Я люблю проговорить и с заказчиком и с разработчиком голосом каждую строчку. Хоть все от этого морщатся, но часто такие моменты нащупать позволяет до поездки в медвежий угол -)
Я люблю проговорить и с заказчиком и с разработчиком голосом каждую строчку. Хоть все от этого морщатся, но часто такие моменты нащупать позволяет до поездки в медвежий угол -)
По-моему, тут все очень просто. Заказчик дает мутнейшее «ТЗ», обсуждаешь с ним подробности и детали, сам пишешь ТЗ (в идеале за деньги). Потом работаешь по прекрасно прописанному ТЗ.
Все что не описано – все за доп. оплату.
Все что не описано – все за доп. оплату.
Sign up to leave a comment.
Не по ТЗ