Не по ТЗ



    Умоляю, уберите скорее от экранов перфекционистов и беременных своей чудесной идеей заказчиков. Пост содержит боль. И вообще, проконсультируйтесь с вашим психотерапевтом.

    Я — аналитик и уже привык: все и всегда происходит не по ТЗ. Это норма, и удивления давно у меня не вызывает — я уж стал думать, что так оно и надо. И тут внезапно увлекся машинным обучением, пошел на курсы, а там надо сделать задание по программированию, а потом проверить три чужих таких же. Я посмотрел на то, как разработчики выполняют учебные задания, и в голове сразу же сложился пазл, как же это все так получается-то.

    Сразу же хочу ответить на несколько важных вопросов.

    А может, это не настоящие программисты, а просто начинающие безрукие упыри?


    Нет! На этих курсах есть этап знакомства, и там все обычно пишут, что давно в разработке и решили квалификацию повысить. Да и сами курсы — довольно-таки зубодробительные, с большим количеством матана и линейки. Не для джуниоров совсем.

    А как же можно проверять чужие задания, если ты сам не шаришь?


    Задание устроено гениально! Вам дают код, и в нем есть места, куда нужно самому дописать свой код, а есть места, где нужно ответить на вопросы текстом, сделать выводы и обобщение. Когда проверяешь сокурсников, то иногда понимаешь, как ту же функцию можно было реализовать иначе. Кайф!

    В чек-листе примерно 40 вопросов, в духе: “В задании просили вывести 12 признаков, а не 13. Проверьте, действительно ли признаков 12.”.

    Все дело в том, что убрать 13-ый признак оказалось не так легко. Пришлось изрядно вкурить доков, чтобы научиться просто так, опа, и убирать 13-ый признак в ассоциативном массиве, не городя дурацких циклов.

    Ну хорошо, ты проверял задания разрабов, с каким-то опытом, и что же тебя там так поразило?


    А поразило меня, ребята, повальное наличие 13-ого признака. Просто никто не стал заморачиваться!

    40 тестовых вопросов я бы разделил на группы:

    * Нужно использовать какой-то метод, о котором написано. Обычно, все справляются.
    * Нужно реализовать какую-то задачу. Обычно, тоже справляются.
    * В этой задаче нужно учесть важные детали. Есть детали простые, например, подписи к графикам. На это все забивают. Хотя в каждом чек-листе на проверке есть пункт “А есть ли у графиков подписи?”. Сижу, проверяю задания — ни у кого нет подписей!

    Дальше есть мелочи, о которых не сказано, как они делаются. Ну, например: “Вывести коэффициент альфа”. Чтобы его вывести, нужно немного вкурить доки или догадаться. Почти все забили.

    И еще есть мелочи, с которыми нужно задолбаться: “Вывести минимальный коэффициент альфа для каждого столбца”. А такого метода нет, нужно делать вручную — никто не стал заморачиваться.

    Ну это же мелочи! Главное, ведь, понять принцип во время обучения! Что ты привязался?


    Во-первых, посмотреть, например, альфы просто необходимо для понимания принципов. Во-вторых, есть еще вопросы типа “вывод”, и если неряшливо относиться к мелочам, то в выводах начинается жара. Например, у человека на графике “шпилька” в потолок, а он в выводах пишет, как все красиво сходится к теоретическому нормальному распределению.

    Ну ладно гнать! У тебя у самого, что ли не было багов?


    Были. У меня тоже ничего не сходилось. Это было видно, и я переделывал. Я замучался с 13-ым признаком, замучался с альфами.

    Надо просто пилить код, пока корректный ответ на вопрос задания не будет найден. И, в отличие от реальной жизни с недоделанными вопросами, дальше не пропускают.

    И тут меня впечатлил второй важный момент. Для того чтобы вкурить, как все работает, приходилось много гуглить. И, естественно, попадались чужие проекты. Многие даже в Гитхабе. А какие-то — висящие на домене какой-нибудь конторы, которая предлагает свои услуги по разработке. Хотя вываливать задания, конечно, запрещено. Но кто читает правила? Ну так вот, мое грустное открытие в том, что очень многие авторы этих проектов бросили обучение год, два или более назад.

    Да что там говорить! Был даже парнишка, который заморочился и выбросил-таки 13-ый признак из списка, и даже одну альфу вывел. Вот, правда, под конец этот супермен подустал, поэтому забил на графики вообще, а в выводах написал: “Ну тут все аналогично.”

    Благодаря этому опыту, у меня родилось понимание, как же все происходит не по ТЗ


    Сделали несколько пунктов, дальше заморачиваться не стали, а потом устали, время поджало, и вообще кусок решили не делать.

    Ну, не то чтобы я этого раньше не понимал, и не то чтобы я сам в этом плане безгрешен, но тут прямо все, как на ладони. Сижу, делаю задания с альфами и сразу понимаю, что не увижу их на проверке.

    Да знаю я этих рукожопов, я не такой!


    Конечно, иногда попадаются разрабы высокой четкости. С ними есть сложность: они как посмотрят на ТЗ, в котором есть мутные места, так сразу говорят: “Тут какой-то бред, я с таким не работаю!” Год не работают, два не работают, начинают голодать и таки ввязываются в какой-то ад. Ну или думают: “Ну его нафиг! А стану-ка я лучше инструктором по парашютному спорту или скалолазанию”.

    А бывает еще такой вариант. В ТЗ все — очень четко, разраб забил и давай юлить: “Ой, у тебя запутано! Ой, а я думал не так, а по-другому.” И клиенты тоже любят: “Ой, а мы думали, что это само собой разумеется.”

    Вместо заключения: “И как с этим жить?”


    Да так же, как и раньше жили:

    — обязательный чеклист по каждой задаче;
    — мало пунктов на каждый этап;
    — обязательное обсуждение каждого пункта голосом;
    — короткие спринты.

    Конечно, заказчик хочет полный фарш, и чтобы ему показали обязательно готовую систему. Надо этому сопротивляться и с болью формировать чеклист из малопунктов на короткий этап. И да, я люблю голосом проговорить каждый пункт и с заказчиком, и с разрабом. А еще люблю прописать прямо в ТЗ, что реализовано не будет.

    А бывает, забью на что-то из этих светлых принципов зачем-то и страдаю…

    PS: zharikovpro дополняет, про чеклисты на основе макета:
    Как вы грешите?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 101
    • +15

      По этому поводу есть характерный анекдот.


      — Что надо сделать для того чтобы спутники успешно выходили на орбиту?
      — Отправлять их туда вместе с их разработчиками.

      • +6
        С ними есть сложность: они как посмотрят на ТЗ, в котором есть мутные места, так сразу говорят: “Тут какой-то бред, я с таким не работаю!”

        Хм, аналитик написал мутное ТЗ, но виноват разработчик? Интересно.
        Я, как разработчик, не работаю с мутным ТЗ, потому что не понятно, что именно я должен сделать. Я понял написанное вот как-то так, аналитик имел в виду другое, а заказчик вообще хотел третье. Написано ТЗ непонятно, неоднозначно или неполно, я иду и пинаю аналитика, чтобы у меня было полное, ясное и однозначное ТЗ, это его работа в конце концов.
        Может быть я работаю в какой-то особой конторе, но у нас если реализация отличается от описанного в ТЗ, то её просто не пропустит QA и отправит обратно на доработку.
        • 0
          Понимаю вас. При этом чем хорош случай с курсами, что там все однозначно. Нужно написать код, и получить совершенно однозначные результаты, которые либо проверят однокурсники, либо проверят парсеры.

          Значит дело не всегда в мутных ТЗ?

          Кстати про мутные ТЗ, я в позапрошлой статье тоже писал «ТЗ высокой четкости»
        • +1

          Неясная ситуация
          Есть ТЗ, есть несоответствие результата с ТЗ
          Если оплата прошла — значит ТЗ было мутное или нужно не то, что в ТЗ, или оно вообще не нужно ТЗ(оно для проформы)
          Какие еще варианты?

          • +1
            Бывает, когда в чек-листе 40 маленьких однозначных пунктов, и чего-то не хватает -)
            Не сталкивались?
          • +6

            Я разработчик, и я с ТЗ не работаю. Вместо этого я работаю по постановкам, написанным аналитиками. И там зачастую написана какая-то хрень. Есть у нас пять аналитиков, которые умеют писать постановки, остальные пишут дикую хрень.


            Когда мне прилетает слишком дикая постановка — я отказываюсь по ней работать пока ее не приведут в порядок (при поддержке начальника отдела и ведущих программистов), одного аналитика я так довел до слез. Но чаще бывает что постановка в целом понятная, но пара абзацев в ней — хрень. Или мне нужно исправить баг в программе, которую писал кто-то другой… по постановкам в которых была написана хрень.


            И когда в такой постановке оказывается слишком много хрени, я ее начинаю пропускать и могу уже не заметить действительно важную информацию.


            Разновидности хрени:


            1. Код прямо в постановке


            К примеру, однажды мне довелось чинить ETL-процедуры. На каждую из них была написана постановка, в которой был приведен код SQL-запроса который нужно было выполнить. И этот запрос на сотню строк работал неправильно: либо пропускал строки, либо дублировал их, либо просто выполнялся слишком долго. Ну и как его чинить-то когда он записан в требованиях?


            И даже если опустить формальности — как понять что этот код должен был делать?


            2. Ритуальные заклинания


            Когда делается много типовых модулей — то программисты выносят повторяющиеся вещи в компоненты или подпрограммы. А в постановках аналитики обычно используют копи-паст. Подобные блоки скопированного текста превращаются в ритуальные заклинания, сопровождающие каждую новую постановку. И когда в очередной постановке эти заклинания оказываются чуть-чуть в другом порядке — никто этих изменений не замечает пока не прилетает блокер с прода.


            3. Копи-паст внутри постановки


            Допустим, есть объекты пяти разных типов, которые нужно обрабатывать одинаково, и еще один тип объектов с особой обработкой. Что делает аналитик? Он копирует описание первого типа объектов 4 раза, исправляя название.


            А потом программисту надо в уме делать дедупликацию. Иногда получается неудачно.

            • 0
              Согласен, это все очень печально и приводит к ложной реализации. Стараюсь избегать такого в работе и даже писал уже в позапрошлой статье про «ТЗ высокой четкости» про примеры адовее ваших -)

              При этом курсы хороши тем, что в курсах с ТЗ все в порядке. Они реализуемы и пропущены через многих разрабов, которые там повышали уже квалификацию.
              • –4

                А все просто: надо постановку писать псевдокодом

                • +2
                  Это кодерам надо такие постановки писать а не разработчикам.
              • +4
                ТЗ высокой чёткости требует высокого опыта разработки. Нельзя написать чёткое ТЗ на средний проект простому смертному и не забыть ничего. Я в разработке уже 15 лет и сколько бы не стралася довести ТЗ до идеала, всё равно есть просчёты с которые попросту не учёл. И это не связанно с тем, что мало опыта, просто на большенство клиентов не хочет платить за потраченное время на написание ТЗ, по этому пишется сокрашённая версия с десяток страниц и всё. А далее уже всё в процессе, ну всё самое важное и значимое естественно расписанно…
                • +2
                  Скажу вам больше. На супер четкое ТЗ большого может жизни не хватить -) А может не хватить жизни на его прочтение.

                  С другой стороны, маленькие проекты, или маленькие этапы отлично документируются.

                  Однако, большие системы все равно приходится описывать, оценивать, проектировать. По возможности работоспособными -)
                  • +1
                    Согласен полностью, что на большой проект не хватит жизни. Я говорю про маленькие и средние а у средних уже начинается конкретные запарки. Мы не в силах продумать все нюансы и многое вылазит только в процессе.

                    В 90% случаях я не получаю ТЗ от клиентов… мне говорят, что приблизительно им нужно.

                    Я пишу ТЗ на понятном языке для клиента, после спрашиваю, всё ли это? Если он говорит, да, вроде бы всё, я его предупреждаю о том, что если мы что-то забыли в ТЗ, то возможно это будет доработка сверху, всё зависит от сложности.

                    Пишу ТЗ для программистов, прохожу проект с главным программистом. Накидываем структуру базы и определяемся по цене.

                    После я подписываю договор с клиентом.
                    • 0
                      Согласен, у меня тоже с годами приключений все пришло к похожей схеме -)
                • +3
                  Как автор отметил — есть разработчики которые придираются к ТЗ, ибо в нем много темных мест и есть разработчики которые делают так как написано и как понятно им и не уделяют внимание каким то хитрым особенностям требований. Про первых все понятно — но как правило им говорят смирись и работай. Про вторых, вообще это стиль работы, делай что понятно, непонятное потом разберем. Как правило никто не хочет ждать пока разберутся с требованиями, простой работы программиста никому не нужен, плюс все равно хотят увидеть что получилось в первом приближении и доработать требования — поэтому всегда торопят, а потом создается приличный скоуп багов, и журят программистов что они все еще косячут. Да и к тому же любое требование может представить всегда в ином свете.
                  Поэтому, все гораздо проще — проблема именно в ТЗ, ибо оно не передает эту информацию для программиста в правильном ключе.
                  • +1
                    Когда мне не задают вопросы по ТЗ, я уже начинаю напрягаться. Обычно причина одна: «не читал». Так что, если придирается, значит читал, круто!
                    С другой стороны конечно нужно смериться и ехать. Максимальная детализация в обозримые горизонты времени даже по маленьким задачам не достижима обычно.

                    И все же, история с курсами отлично показывает, что проблема не всегда в ТЗ. Там-то ТЗ всегда однозначные! Их уже выполняли многие разрабы за несколько лет. Получали результаты, которые можно было на парсере проверить к примеру -)
                  • +1

                    Сколько заданий вы проверили? Скольким различным учащимся они соответствуют? Сколько из них допускали приведенные ошибки?

                    • +1
                      По началу проверял по 10-12 на каждую тему, никак не могу поверить. Теперь устал, проверяю по 3 (это минимум для зачета) на каждую тему, все одно и то же. Причем люди разные всегда, т.к. я медленно учусь и отстаю, люди меняются за время пока я тему прохожу.

                      Последний раз проверил 3 задания и во всех были приведенные ошибки. В предыдущем курсе 80% где-то не ставили подписи к графикам. Специально исследования не проводил.

                      Конечно можно прямо взять и посчитать репрезентативную выборку, оценить ЦА, посчитать отклонения. Если бы хотел бы дисер про это писать — занялся бы. А так не достаточно энтузиазма -)
                      • 0

                        Тогда да, похоже на системное заболевание. А народ в основном с высшим или нет?

                        • +1
                          Там без высшего смысла нет, в первых же лекциях матричное исчисление, системы линейных уравнений, регрессия, центральная предельная теорема. Думаю, что ребята без высшего технического, ну хотя бы без первых 2-3 курсов срезались на первых же лекциях.
                          • +2

                            Ну я без высшего, но курс ODS в первой двадцатке закончил, затем окунулся в kaggle. Математика осваивается или самостоятельно или, к примеру, с онлайн курсами.
                            Мне поэтому не очень понятен ваш комментарий. Выпускник тех вуза может знать или не знать математику, чаще, наверное, знает, но correlation doesn't imply causation.

                            • 0
                              Есть самородки, не спорю. При этом одно дело вспоминать, и другое дело по сухому с нуля. Не каждому дано.

                              Если у вас дар, не стоит это экстраполировать на всех -)))
                              • 0

                                Вот интересно, самородками можно назвать персонажей без высшего, способных пройти курс.
                                А какой эпитет подобрать для персонажей с высшим, которые не могут осилить? Полагаю таких ой как немало, относительно общего количества получивших в.о.

                                • 0
                                  Я на последних курсах преподаю бывает тех. вуза, так вот не все знают что такое функциональная зависимость.
                            • 0
                              Их там прямо доказывают, включая ЦПТ?
                              • 0
                                ну нет -)
                                без доказательств, но с лабораторными -)
                      • +1
                        > И как с этим жить?

                        Расширю имеющийся список. Чтобы не забыть про мелочи, я пишу чеклисты приемки на основе макета. Макет — очевидное представление результата, по нему можно визуально быстро понять если результат совсем негодный. Если в целом выглядит нормально, можно дальше по чеклисту проверять. Можно и на самом макете подписать пункты чеклиста, если они короткие. Пример из статьи про графики тут замечательно подходит.
                        • 0
                          Тоже люблю делать чеклисты, забыл про это добавить -))))
                        • –1
                          > Благодаря этому опыту, у меня родилось понимание, как же все происходит не по ТЗ

                          Все дело в мотивации, имхо. Она напрямую вытекает из схемы организации труда. За что разрабу платят, то он и делает.

                          Например, сидит в конторе штатный разраб и каждый месяц получает зарплату. Т.е. ему платят за присутствие в офисе. Денежной мотивации делать все сразу все по ТЗ и без багов у него нет, он и не делает.

                          В это же время на фрилансе разрабу платят за результат по ТЗ и без багов, а все дефекты (несоответствие ТЗ и баги) разраб устраняет за свой счет. И НЕ получает денег и новых заказов от заказчика, пока не устранит дефекты. Тогда разраб замотивирован делать все сразу правильно и в полном объеме.

                          Тут я сознательно утрирую, конечно есть промежуточные варианты. Многие фрилансеры также безответственно подходят в работе как и штатные сотрудники. И тогда у них закономерно будут хронические проблемы с поиском и удержанием доходных клиентов.
                          • +3
                            А мне кажется дело в культуре. Вот есть люди, которые и за деньги и без денег вовсе будут делать правильно. Просто потому, что они верят, что надо делать правильно.

                            А есть люди, которым сколько не плати, сколько не штрафуй — ничего не меняется, одно расстройство.
                            • 0
                              > А мне кажется дело в культуре. Вот есть люди, которые и за деньги и без денег вовсе будут делать правильно.

                              Есть, но таких очень мало. Если не организовать работу на результат, «бескультурные» будут его портить и снижать эффективность.

                              Если отбирать только «культурных», то все равно есть риск ошибиться при найме, да и человек потом может разлениться.

                              Если же отбирать «культурных» людей и работать по правилам, которые дают результат — получается комбо. Но в таком случае даже не нужно как-то специально отбирать «культурных». Достаточно просто выбирать людей, которые будут работать по правилам эффективной организации труда. «Некультурные» такой фильтр не пройдут. А даже если и пройдут — быстро вылетят из системы, налаженной на эффективное производство результатов.
                              • 0
                                > Вот есть люди, которые и за деньги и без денег вовсе будут делать правильно.

                                Можно назвать это культурой, можно назвать внутренней нематериальной мотивацией (в отличие от внешней материальной, например оплаты). Вообще нет противоречий, полный консенсус :)
                                • +1
                                  Не, культура — это наживное.

                                  Научить людей делать хорошо может лет 5 занять. А попробуйте полгода поштрафовать тех, кто делает правильно за то, что делают правильно. Ну как штрафовать… Можно лишней работой «премировать».

                                  • +1
                                    Ахха, не я был инициатором, но наблюдать доводилось много раз.
                                    Очень увлекательный опыт.

                                    Главное открытие: никто не разбегается!
                                • 0
                                  P.S. Сам отношу себя к разработчикам высокой четкости (меткое выражение!). По мере развития скиллов все больше заинтересован в том, чтобы обе стороны работали на результат по принципу «поставленный продукт без дефектов = заработанные деньги».

                                  Это устраняет кучу проблем с ведением проекта и выгодно обеим сторонам. Клиенту — т.к. он предсказуемо получает именно то что оплатил и мотивирует исполнителя на эффективность — максимально быструю выдачу запланированного результата. Исполнителю тоже хорошо, т.к. он получает бонусы за экспертизу и эффективное решение задач, а не за потраченные часы.
                                  • +1
                                    С такими разрабами всегда приятно работать, хоть и сложно. Требует самодисциплины -)
                                    • 0
                                      Почему сложно? Проанализировали задачу, спроектировали решение, реализовали, приняли (т.е. заказчик протестировал) — деньги в кассу пожалуйста, получите и распишитесь.

                                      А без дисциплины со стороны заказчика никто из исполнителей классный результат не даст, имхо. Если кто лично знает контрпримеры — тому приз в студию!
                                  • –2
                                    За что разрабу платят, то он и делает.

                                    Задача менеджера жестко пресекать подобное отношение к работе. Согласился работать — работай хорошо. Не устраивает зарплата — скажи. Всё равно не повышают — уходи.

                                    • 0
                                      Подобное отношение к работе — самое честное и цивилизованное.

                                      Понятие «хорошо» — субъективно. Представьте, интернет-провайдер предложит вам услугу с «хорошей» скоростью за «недорого» и скажет, что его менеджеры будут следить за тем, что скорость будет «хорошей», а цена — «приемлемой». Согласитесь подписать? Почему-то это не считается годным договором, прописывают скорость в Мб/с и оплату в рублях по тарифу т.д. и т.п. Аналогичная ситуация и с сотрудником, который предоставляет услугу нанимателю по договору.

                                      Если к работе разработчика есть какие-то объективные требования — их стоит прописать в договоре, должностных инструкциях и т.д. и т.п. вместе с численными критериями и способами объективного измерения. Если это сделать не получается, значит критерий — либо опциональный, либо субъективный, либо и то и другое. Если критерий опциональный и/или субъективный — зачем вообще следить за его соблюдение и платить за это менеджеру и разработчику?

                                      Важно ответить на вопрос «зачем» с точки зрения владельца бизнеса и в разрезе того, как выполнение условий увеличит прибыль компании. При тщательном исследовании вопроса ряд «требований» менеджеров оказывается не более чем их самоуправством и вкусовщиной из серии «я так вижу, я так хочу», густо замешанной на синдроме вахтера.
                                      • 0

                                        Когда между работодателем и сотрудником отношения требуют столь подробного документального описания, когда для решения рабочих вопросов стороны апеллируют к пунктам трудового договора и должностных инструкций, на мой взгляд для обоих лучше расстаться.

                                        • 0
                                          > Когда между работодателем и сотрудником отношения требуют столь подробного документального описания

                                          Отношения между работодателем и сотрудником — не требуют. В вашем примере только менеджер что-то требует от разработчика. Почему, зачем, что такое «хорошо работай» — понятно примерно настолько же, насколько и ТЗ «сделайте нам классный сайт, чтобы было хорошо!»
                                          • 0

                                            Вопрос на самом деле отличный. редко кто его поднимает, просто за время ИС сотрудник обычно понимает чего от него ждут. Если есть ощущение что сотрудник и руководитель по-разному понимают что значит "хорошо работать", нужно сесть вдвоем, обсудить и согласовать тезисно, чтобы это было принято обеими сторонами. Можно зафиксировать протоколом.
                                            Если договориться не удалось, можно попробовать апеллировать к вышестоящему руководству или расстаться. Как-то так.

                                            • 0
                                              > просто за время ИС сотрудник обычно понимает чего от него ждут

                                              Т.е. каждый новый сотрудник во время ИС вынужден методом проб и ошибок выяснять то, что в компании уже давно и так известно. Такой способ обучения сотрудников расточителен для компании.

                                              Я осознаю, что все что я написал выше — крайне непопулярно. Точно так же, как и хорошо организованные, прибыльные, стабильно растущие бизнесы — большая редкость. Интуитивно чувствую тут корреляцию.
                                              • +1

                                                Все зависит от размера бизнеса.
                                                Если это энтерпрайз, там наврняка будут инструкции на все случаи жизни.
                                                Маленькая компания — точно нет, и никто не скажет чего от сотрудника понадобится завтра.
                                                Средние — где-то между этими крайностями. Если бизнес быстро растёт — в нём всё быстро меняется. В том числе меняются требования к сотрудникам.


                                                Вопрос, в каком варианте конкретному человеку комфортнее. Я вот по себе знаю, что точно не хочу работать в компании где чётко прописаны инструкции на все случаи жизни. По мне лучше продуктивный хаос небольшой компании. Это интереснее.

                                                • +1
                                                  > Маленькая компания — точно нет, и никто не скажет чего от сотрудника понадобится завтра.

                                                  Именно поэтому странно пост-фактум требовать «делать хорошо» то, к чему еще вчера никто не был готов. В своих комментариях я возражал именно против такого сваливания ответственности с больной головы на здоровую, и только.

                                                  И т.к. в маленькой компании «никто не скажет что понадобится завтра» -именно поэтому там платят разрабам за «доступ к телу» в первую очередь, а далее — по ситуации, часто непредсказуемо.

                                                  Ну и конечно, все варианты жизнеспособны — выбирай на вкус.

                                                  Вот мы и подошли к логическому завершению дискуссии. Спасибо за конструктивный диалог!
                                                  • 0

                                                    Спасибо и вам

                                              • 0
                                                > Если есть ощущение что сотрудник и руководитель по-разному понимают что значит «хорошо работать», нужно сесть вдвоем, обсудить и согласовать тезисно, чтобы это было принято обеими сторонами. Можно зафиксировать протоколом.

                                                Конструктивно! Предлагаю пойти дальше и на основании протокола исправить изначально дырявые договор и инструкцию, которые и допустили такую ситуацию. Тогда в будущем на решение тех же вопросов не придется тратить ресурсы почем зря.
                                                • +1

                                                  Я давно подозревал, что из программистов получаются прекрасные юристы ;)

                                        • 0
                                          Считайте, что договор между работодателем и исполнителем описывает ТЗ и критерии приемки работы исполнителем. Без ТЗ закономерно получается ХЗ.
                                          • +1
                                            > Согласился работать — работай хорошо.

                                            Имхо, работать хорошо — это когда довольный клиент платит снова и снова. Программисту платит не менеджер, а заказчик. Поэтому и критерии «хорошей работы» — не менеджеру определять в первую очередь, а заказчику.
                                            • 0

                                              Программисту платит работодатель а не заказчик. Заказчик может сегодня быть а завтра — нет, а зарплата остается. Поэтому работу программиста оценивает именно тот кто непосредственно платит ему деньги.
                                              Кроме того, работа программиста как правило это лишь часть объема услуг, за который заказчик платит деньги.

                                              • 0
                                                > Программисту платит работодатель а не заказчик.

                                                В этом случае работодатель и есть заказчик для программиста с точки зрения программиста, в коммерческом смысле слова.

                                                Если труд программиста перепродается и есть т.н. внешний заказчик — он является прямым заказчиком для работодателя программиста и лишь косвенным для самого программиста. Такая иерархическая цепочка.

                                                Клиент — полный синоним слова заказчик;
                                                Покупатель — синоним слова заказчик;


                                                > Кроме того, работа программиста как правило это лишь часть объема услуг, за который заказчик платит деньги.

                                                А это не важно, мы же про программистов и их услуги говорим. Так вот программист оказывает на заказ именно услуги программирования. Тому кто за это платит.
                                                • 0
                                                  В этом случае работодатель и есть заказчик для программиста с точки зрения программиста, в коммерческом смысле слова.

                                                  Да, приходилось работать в компаниях, где между программистом и тем кто ставит ему задачи отношения были в духе заказчик-исполнитель. Где-то само так случилось, где-то, представьте, насаждалось искусственно! Кончалось всё тупиком. В конце концов "Заказчик" топал ногами, кричал, ругался, требовал. "Исполнитель" отбивался пунктами ТЗ, инструкций и pocker-face'ом. При этом оба получали стабильную зарплату а проекты тем временем затягивались на годы.

                                                  • 0
                                                    > При этом оба получали стабильную зарплату а проекты тем временем затягивались на годы.

                                                    Это про бизнес и работу. Остальное — шелуха. Если заказчик «негодует» и продолжает платить исполнителю — значит его это устраивает.

                                                    В капитализме на свободном конкурентном рынке есть такая офигенная фишка, что если совсем не устраивают результаты работы одного исполнителя — просто меняешь его и платишь за то что устраивает. А за то что не устраивает — не платишь.

                                                    Описанная вами ситуация — точь в точь «мыши плакали, кололись, но продолжали жрать кактус». Ну, бывает — заказчики люди, могут вести себя иррационально.
                                                    • 0
                                                      P.S. Если заказчик не может уволить и заменить исполнителя — значит он и не заказчик вовсе. Кто может уволить исполнителя / разорвать договор / перестать платить за работу — тот и есть истинный заказчик для этого исполнителя.
                                                      • 0

                                                        Все верно, только есть ТК РФ, по которому ни уволить ни даже в деньгах прижать не получится без последствий. В нормальных коммерческих отношениях это рядовые инструменты взаимодействия заказчика с исполнителем.

                                                        • –1
                                                          К сожалению, ТК РФ как и прочая бюрократия имеет мало общего с продуктивной работой.

                                                          Как организовать работу например ООО так, чтобы и продуктивно и по ТК РФ — организационный и юридический вопрос за пределами нашей дискуссии. Предполагаю, что при должной мотивации руководства это возможно. Но тут я некомпетентен и технических подробностей не знаю, легко могу ошибиться.

                                                          Из своего опыта скажу, что на фрилансе и при работе с ИП такой проблемы с ТК РФ точно нет.
                                                          • 0
                                                            Из своего опыта скажу, что на фрилансе и при работе с ИП такой проблемы с ТК РФ точно нет.

                                                            Таких — точно нет, но есть другие. Заказчику нужно больше работы за меньше денег, исполнителю — наоборот. Фундаментальная мотивация разная. От этого уже конкретные проблемы растут. Но это уже совсем другая история.

                                                            • 0
                                                              > Заказчику нужно больше работы за меньше денег, исполнителю — наоборот.

                                                              Так это в рыночных отношениях везде и всегда так, разве нет? Все ищут самые выгодные условиях. Т.е. ROI повыше — вложил поменьше, получил побольше.

                                                              И это не проблема, а стимул, благодаря которому конкурирующие исполнители замотивированы на повышение производительности труда. И благодаря конкуренции заказчик получает все лучшие и лучшие предложения. Это и двигает прогресс.
                                                              • 0

                                                                В целом конечно да, но в одном конкретном проекте — это всегда проблема.

                                          • 0
                                            В голосовалке нужен еще вариант «Руководство не предоставляет ТЗ. Работаю на интуиции»
                                            • 0
                                              про это я уже писал, статья «Без ТЗ» называется -))))
                                          • +9
                                            Я помню как-то давно обсуждал ТЗ с заказчиком по проекту. Обговорили функционал, описали в общих чертах. Потом я с командой обсудил, описал все технические моменты. В общем, все было весьма точно и без «тяп-ляп». Принес заказчику, он увидел, обрадовался. И я говорю:
                                            — Ну что, подписываем и мы принимаемся за работу?
                                            — Да, отлично! Если что-то еще изменится, я позвоню.
                                            — Как изменится? Мы же уже ТЗ подписываем, на этом этапе уже ничего не должно меняться, будет реализовано как описано. Если вдруг что-то нужно будет, то мы готовы по доп. соглашению отдельно потом реализовать.
                                            — Т.е. за дополнительные деньги?
                                            — Конечно. Текущая стоимость покрывает только то, что описано в ТЗ.
                                            — А вдруг я что-то упустил или мне надо будет что-нибудь поменять?
                                            — Так для этого вы же и брали время на изучение ТЗ.
                                            — Ну, я его изучал, но не с этой стороны. Там все, как-то, слишком досконально, я не вчитывался так глубоко. Может мы более общие моменты утвердим, чтобы, так сказать, иметь свободу в деталях?

                                            С тех пор, сколько я ни смотрю на ТЗ, понимаю, что большинство, с обоих сторон, умышленно оставляют себе «свободу в деталях». И в ТЗ смотрят, когда либо проект очень большой и ответственный, либо хотят «продавить» контрагента.
                                            • +2
                                              Я обычно «свободу в деталях» стараюсь выносить в отдельное приложение к договору за отдельную стоимость еще на стадии сметы.
                                              В духе
                                              — 100 часов на доработки?
                                              — да!
                                              — а не будет у нас доработок!
                                              — точно?
                                              — 100%
                                              — договорились
                                            • +1
                                              У меня противоположенная проблема. Задача пришла в разработку, а потом все начинают менять ее. Тестировщику что-то не понравилось, он пошел обсуждать с менеджером, еще может влезть в спор пыха-разработчик. Дизайнер уступает и соглашается на изменения.
                                              Посмотрело начальство, еще что-то велело поменять, и задача на выходе совсем не похожа на свое описание. Я стала говорить, что все желающие могут посмотреть макеты и высказаться дизайнеру, что их не устраивает, а если они этого не сделали, то их проблема, после отправки на тестирование ни какие изменения вне рамок макетов вноситься не будут. Что еще можно сделать?
                                              • +3
                                                Ходить по воде и разрабатывать программы согласно ТЗ очень просто, если они заморожены (с) E. Berard
                                                • +1
                                                  Все-таки «все желающие» могут затянуть создание даже самого простого макета на годы. Нужно договориться, чтобы утверждением макета занимался один единственный человек.
                                                  Тогда можно записывать пакет правок, которые этот человек согласует в работу.
                                                  Это может быть: артдир, менеджер проекта, аккаунт и т.д., как договоритесь.

                                                  Если дизайнер будет ходить и собирать правки со всех, то когда же он будет рисовать? -)))
                                                  • 0
                                                    Ах, если бы у нас за год сменилось порядка 6 менеджеров. Нежные они какие-то.
                                                    Приоритеты меняются чуть ли не каждые два дня.
                                                    • 0
                                                      И как вам удается вообще как-то работать?

                                                      Ну разве что воспринимать промежутки между сменой власти как спринты -)
                                                      • +1
                                                        Да вот по ходу предпоследнего я напугала. Все было норм, я возлагала большие надежды на девушку, она отработала полторы недели у нас и добралась побеседовать со мной. Я рассказала о проблемах, в основном про приоритетность задач, что все хотят свои задачи и срочно.
                                                        Пыха-программисты сделали какие-то своих задачи и требуют, что бы я дописала для них фронт, тестировщик что-то нашел и это тоже надо срочно фиксить. У маркетологов через три дня акция стартует, а у нас еще конь не валялся, начальство вообще хочет совсем другие задачи и тд и тд. Вот ей требовалось выслушать весь этот поток страждущих, разобраться, что действительно важно и скомандовать нам какие задачи, когда делаем, а какие пока откладываем. Там еще ряд моментов. Через пол часа узнали, что она решила уволиться.

                                                        Как работаем, ближе всего кан бан. Есть набор задач, выполняем из него, если что-то долгое, то делаем от нескольких дней или до нескольких недель, разбавляя процесс мелочовкой, занимающей от силы часик, полтора в день. Потом тестирование, еще ввели дизайнерскую приемку, они прямо в задачах подписывают, что принимают. Просто пищали, что не по макетам и жаловались начальству, что боятся ко мне подходить(сомнительное карьерное достижение, конечно).
                                                        Вообще мне нравится, что они принимают, порой глаз замылился, а они сразу видят, где отступ не совпадет или значок ниже, чем другие.
                                                        Еще случаются дни мелких задач, делаю дня два задач по 7-10 в каждый.
                                                  • 0
                                                    Во-первых точно фиксировать в ТЗ изменения (всегда иметь актуальную версию того, что реально делают/сделали) + вести историю изменений(кто, на каком этапе, что и почему изменил) + вести трассировку с другими требованиями + следить за трудозатратами. Требования в целом вещь живая…
                                                    Разумеется меняем ТЗ если изменения разумны и состав менеджеров/клиентов это не вгонит в депрессию. Изменения согласуем с участниками, оглядываясь на трудозатраты и текущие правила игры.
                                                    И я вообще не верю, что в средней/большой задаче нужно прям 100% всего разжевать, это может быть не рационально по времени. В процессе реализации задачи на языке программирования в конкретном проекте всегда имеют место быть нюансы, которые «дешевле» бывает подогнать на месте глядя в текущий код. Разумеется речь не о фатальных промахах ;)
                                                  • +8
                                                    4 года я был аналитиком и руководителем проектов.
                                                    И я считал свои ТЗ отличными и понятными. Я правда над этим много работал. Например, мне однажды попадалась подробная анкета на верстку от топового фрилансера на fl.ru, с 500+ положительными отзывами. Анкета состояла из 30+ пунктов поверх очень хороших макетов. Я из нее взял пунктов 10, и стал использовать на всех этапах, от ТЗ до приемки.

                                                    Но только став разработчиком, я понял, что все мои ТЗ были говно
                                                    Не в том плане, что неправильные. Просто не до конца проработанные. Конечно я и с ними добивался поставленных целей, но благодаря тому, что и дизайнеры и разработчики на своих этапах превносили в работу огромное количество полезных уточнений.

                                                    Например в ТЗ есть форма регистрации на 5 полей
                                                    99% ТЗ содержат перечень полей:
                                                    *Имя
                                                    *Email
                                                    День рождения
                                                    Телефон
                                                    Комментарий
                                                    Город

                                                    И поставив звездочки около имени и email заказчик, считает, что уже достаточно описал форму. И если есть moqups или дизайн формы — то вообще какие тут могут быть еще вопросы. А так как в его «сайте/портале/CRM/ERP...» таких форм десятки, а страниц десятки типов, то ТЗ уже и так на 50-100 страниц. А значит достаточно подробное)

                                                    Что же мы забыли
                                                    • Валидации полей на типы
                                                    • Валидации полей на лимиты (вряд ли 1800 год рождения — нормально)
                                                    • Валидации полей на уникальность (ну это же очевидно)
                                                    • Где проходит эта самая валидация(на сервере, или в браузере; понятно, что уникальность email мы не можем проверить в браузере, а вот желание проверять валидность и обязательность полей в браузере хорошо бы указать)
                                                    • Ошибки валидации (и даже если попросить их указать, вряд ли вы увидите две разные ошибки на невалидный email и уже существующий)
                                                    • А еще мы забыли уведомления на email, подтверждения телефона, восстановление пароля, авторизацию через соцсети и т.д. И каждый из этих пунктов — это формы, валидации, проверки, тексты ошибок, редиректы после успеха и неуспеха
                                                    • А еще самый коварный вопрос: при авторизации через соцсети, если пользователя с таким email нет, то отказывать в авторизации или создавать нового пользователя? А письмо ему на email в этом случае надо отправлять или нет?


                                                    99% заказчиков и 95% аналитиков неспособны на таком уровне проработать ТЗ
                                                    Заказчики не могут, потому что не понимают уровень детализации, и у них нет времени, а аналитики, потому что чаще всего это просто вчерашние секретари/секретарши, помощники/помощницы. Которые внезапно для себя делают сайт/портал и теперь пишут к нему ТЗ. Как умеют.

                                                    Какие из всего этого я сделал выводы для себя?
                                                    Неважно какую роль я играю: аналитик, заказчик, программист, руководитель проекта — если я вижу, что ТЗ содержит тонны подводных камней, я сажусь и вместе в диалоге его прорабатываю. Как с тем, кто является для меня заказчиком, так и с тем, кто является для меня исполнителем.
                                                    Нет никакого смысла отправлять заказчика доделывать ТЗ, со словами «ТЗ мутное». Он не будет его доделывать, а просто найдет того, кто будет с таким работать. Наступит на все грабли, и справедливо будет считать всех программистов козлами. А ведь у него был шанс, поработать с хорошим программистом, который поможет сделать ТЗ не мутным.
                                                    Также нет никакого смысла отдавать все на откуп разработчикам с мыслями: «Форма регистрации, табличка отзывов, страница профиля — это же так стандартно. Что тут может быть непонятно.» Разработчик в 99% сделает как он делал в прошлом проекте, или как принято в его стеке технологий, или как ему проще и нравится. Его «нравится» редко когда совпадает с чувством прекрасного у заказчика.
                                                    И нет никакого смысла вылизать сразу все ТЗ на 3ё500 страниц.

                                                    Мой рецепт:
                                                    • Разбить проекты на части
                                                    • Выбрать 1 часть. В начале желательно важную для проекта
                                                    • Детально описать
                                                    • Сделать 50%. Задать появившиеся вопросы
                                                    • Доделать, показать, получить правки, доделать
                                                    • Взять следующую часть

                                                    А еще очень важен постоянный диалог в стиле:
                                                    «Мы разбили проект/задачу на 7 частей. Первая часть займет неделю. Мы подготовили вопросы по ней. Сейчас проговорим детали.… (после того, как проговорили детали) Дня через три мы придем с новой порцией вопросов по первой части. А в начале следующей недели так же будем прорабатывать часть 2, подготовьте свои соображения, мы подготовим наши вопросы». И опять же это касается любого участника процесса: как заказчика, так и руководителя проекта, и тимлида, и разработчика, и дизайнера, и даже верстальщика.

                                                    Известно, что энтропия (в данном случае мера бардака в проекте) сама увеличивается, если не прикладывать осознанных усилий к её уменьшению. Так что помогают только осознанные усилия, диалоги, контроль, согласования, умелое отстаивание уже утвержденного, выкидывание лишнего. И только, если все это для уменьшения энтропии, а не снятия отвественности и оставления для себя свободы деталий и вариантов «нагнуть другую сторону»
                                                    • +2
                                                      В целом я это называю: писать ТЗ так, чтобы разрабам хотелось его выполнить.
                                                      • 0
                                                        А если ты разраб, то уточнять детали, чтобы потом не переделывать)
                                                      • 0
                                                        Великолепный коммент!

                                                        В данном детальном описании еще забыли описать хранение служебных данных и структуру БД :)

                                                        Например, обычно полезно хранить дату регистрации пользователя. Модераторам, админу и бизнесу это нужно чтобы смотреть статистику регистраций, анализировать профили пользователей по когортам и т.п.

                                                        Решили что храним дату. Отлично, как в БД запишем — timestamp, timestamptz, в каком часовом поясе и т.п.? И ладно если речь про дату регистрации, это ДСП и в UTC все отлично.

                                                        А вот например в федеральном интернет-магазине нужно хранить дату и время доставки товара с учетом часового пояса и геолокации пользователя (см. раздел «Всё ещё хуже, чем кажется»). То же самое применимо к календарям-напоминалкам.
                                                      • +1
                                                        У большинства ТЗ которые я видел есть одна или несколько из следующих проблем, из-за которых ими тяжело пользоваться:
                                                        1. Они слишком высокоуровневы и абстрактны, не учитывают многих деталей
                                                        2. Они плохо структурированы и их сложно читать
                                                        3. Они быстро устаревают и никто не заморачивается их обновлять (ни разработчик, ни аналитик)

                                                        Как я обычно работаю с ТЗ:
                                                        1. Читаю 1 раз (иногда по диагонали), чтобы понять что от меня хотят
                                                        2. Расписываю ТЗ в виде списка TODO задач с объёмом выполнения 0.5-1 день насколько это возможно. Обычно на данном этапе всплывает много непонятностей и неучтённых деталей, а также ограничений технологий
                                                        3. Разбираю все непонятности с аналитиком и дополняю свой TODO лист
                                                        4. Реализую по списку (позволяет не пропустить мелочей)
                                                        5. В ходе тестирования опять обсуждаем детали с тестировщиком и аналитиком.

                                                        Как решить проблемы ТЗ:
                                                        1. Аналитик должен «владеть» ТЗ. Т.е. поддерживать его в актуальном состоянии. Из этого следует, что аналитик всегда должен быть в курсе изменений
                                                        2. Для разработчика ТЗ более удобен не в виде формального документа, а в виде списка задач в таблице
                                                        3. Аналитик должен проводить подобие UAT после окончания разработки, чтобы убедиться что сделали то, что хотел заказчик.
                                                        4. Тестировщик с аналитиком пишут чёткие сценарии тестирования (желательно ещё до начала разработки)

                                                        • 0
                                                          Моя мечта -)
                                                          • 0
                                                            > Тестировщик с аналитиком пишут чёткие сценарии тестирования

                                                            Лучше когда сценарии приемки вмсте пишут и согласовывают клиент и аналитик. Т.к. в конечном итоге принимать работу будет клиент.
                                                          • 0
                                                            А где же вариант «Пишу ТЗ»?)
                                                            • +2
                                                              Уже 5+ лет занимаюсь работой аналитика. Поработал с разработчиками от разных «полюсов»: как с теми, которые будут докапываться до каждой фразы, причём не стесняясь в выражениях и зачастую с большой долей высокомерия, так и с теми, которым ТЗ не нужен — достаточно постановки и времени на обсуждение.
                                                              Особая острота к работе добавляется, когда у тебя есть определённые компетенции в разработке, особенно в используемом в работе стеке. Как экстремальная форма ситуации — когда разработчики настолько плохи, что даже ты со своими «домашними проектами» их превосходишь в их области (при аутсорсе встречались такие). С одной стороны это огромный плюс — ты способен оценить сложность реализации того, что ты описываешь, ещё до оценки разработчиками, ты знаешь какие вещи реализуемы, какие сложнореализуемы, а какие просто невозможны, ты знаешь, где что-то может пойти не так и где требуется уточнение поведения. С другой стороны, ты «всего лишь» аналитик — большинство разработчиков встретит вторжение в сферу своей ответственности от тебя со скепсисом (осторожностью/враждебностью/возмущением). В итоге приходится постоянно лавировать между «тем, что ты знаешь» и «тем, что от тебя ждут», зарабатывать доверие разработчиков и бороться с внутренним конфликтом «брошу всё уйду в разработчики». К сожалению, это очень распространённая проблема разработчиков — недоверие к опыту не-разработчиков. Впрочем, объяснимая — аналитиков, которые пишут совершенно поверхностные ТЗ очень много.
                                                              Для себя я решил, что идеальная работа — это работа с командой, которая прежде всего всегда готова к обсуждению и готова к свободе своих действий в обмен на риск что-то выбросить и переписать. Можно называть это agile, можно lean, можно даже «пиши код бл*ть» — в любом случае нужно принять возникновение ошибок как что-то неотвратимое и постараться сэкономить время на попытках их предотвратить, потратив это время на создание функциональности. Ну, и мотивация всех на конечный результат, а не закрытие тасков в трекере. Пусть даже внутренняя.
                                                              • +1
                                                                Может быть не так уж и нужно это самое соответствие ТЗ. Часто бывает так, что к моменту когда ТЗ дописано — оно уже устаревает. Да что там ТЗ, даже просто требования. Ну сделали вы все строго по ТЗ, а клиенту продукт в том виде в котором он был актуален ранее — уже не подходит. В конечном итоге задача у вас и у клиента заработать денег, а не заниматься крючкотворчеством.
                                                                • 0
                                                                  Мой свой вариант: пишу ТЗ, которые никто не читает. Даже заказчик.

                                                                  Надо попробовать оформлять сценарии юзкейсов в виде комиксов. И чтобы в последнем кадре персонаж направлял вопросительный взгляд на читающего.
                                                                  • 0
                                                                    Если к заказчику активно не приставать, он и не будет читать ТЗ.
                                                                    А потом скажет, ой, я это первый раз вижу.
                                                                    • 0
                                                                      Заказчик может свято верить в магию технологий и колдунство программистов.
                                                                      Такую веру не просто разрушить просто активными приставаниями.
                                                                  • 0
                                                                    Эм… тесты? Написал тесты, прогоняешь код. Если ТЗ неалгоритмизируемо или его трудно проверить — надо менять ТЗ, точнее, переформулировать так, чтобы можно было.
                                                                    • 0
                                                                      Из чеклиста в ТЗ:
                                                                      n: Должны быть подписи осей на всех графиках.

                                                                      Тест: Есть подписи или нет?
                                                                      • +1
                                                                        (опуская детали реализации):

                                                                        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% хороша.
                                                                        • +2
                                                                          Часто ли вы получали такие ТЗ от живых клиентов или заказчиков? -)
                                                                          • +1
                                                                            А не для этого ли нам аналитики?

                                                                            Алсо, получали. Машиночитаемость взаимодейтсвия с заказчиком — очень частое требование.
                                                                    • 0
                                                                      Многие разработчики когда-то прорешивали SICP и занимались собственными проектами, вылизывая их.

                                                                      А потом пошли работать, и поняли, что платят — за говнокод, главное чтобы его было побольше и в срок. И еще — нужно свалить с проекта раньше, чем он начнёт реально использоваться.

                                                                      Сначала человек читает Рихтера, у которого всё написано по делу. Потом сталкивается с чьими-то хотелками, пожеланиями людей, которые не в состоянии выражовывать свои мысли в письменном виде, но почему-то имеют и аттестат, и диплом, и даже деньги. Разумеется, половину того, что эти люди выражают, приходится отфильтровывать. А если не фильтровать — за это больше не заплатят, но сил останется меньше, чем у бодро кидающих лопатой говнокод и хорошо социализированных коллег.
                                                                      • 0
                                                                        ТЗ? Что такое ТЗ?
                                                                        Я один раз добился ТЗ. Прислали на почту. Думаю ура.
                                                                        Открываю, а там… я незнаю как это назвать, но если я делал бы по ТЗ, то явно получилось что угодно, кроме заказанного.
                                                                        Оказывается, писать ТЗ реально для слабаков. Интернет поможет. Чужой ТЗ, пару страниц правок, а дальше зачем? Получай и делай)))
                                                                        • 0
                                                                          Бывает и нормальные присылают. Не сем так не везет.
                                                                        • +1
                                                                          Если заказчик любимый — делаем то, что ему нужно.
                                                                          Если заказчик нормальный — делаем то, что он хочет.
                                                                          А если заказчик мерзкий — делаем то, что он написал в ТЗ.

                                                                          Был случай год назад — сделали по ТЗ. Написано «web-технологии» — ставим клиента на web-технологиях. Ну и что, что он readonly, ввод из клиента в ТЗ не прописан. Ну значит данные вводятся с сервера, с клиента — только наблюдение за процессом.

                                                                          Выяснилось это все на этапе пусконаладки за 3 дня до сдачи испытаний. В медвежьем углу Волго-Балта. Мда, настолько багрового клиента я ещё никогда не видел. Нам повезло — инфаркта у клиента не было.

                                                                          Да, баг не наш — мы просто сделали по ТЗ. Но все равно — дичайший ляп. Пришлось сдавать через RDP, а потом переделывать.

                                                                          Таких историй довольно много. Ибо ТЗ не застрахован от багов.

                                                                          Вся беда в том, что ТЗ надо тестировать. Но заметить ошибку на этапе ТЗ — сложнее, чем на этапе отладки. И написание и тестирование ТЗ требует высокой квалификации.

                                                                          Так что исправлять баги на отладке — дорого, а добиваться качественного ТЗ тоже дорого.

                                                                          Ну в общем см. рис 1
                                                                          image

                                                                          • 0
                                                                            Да это очень важный момент. Когда вы получили подписанное ТЗ, а в нем чушь, если сделать чушь, то заказчик считает, что виноваты все равно вы. Ну не всякий конечно так считает, но часто, да.

                                                                            Я люблю проговорить и с заказчиком и с разработчиком голосом каждую строчку. Хоть все от этого морщатся, но часто такие моменты нащупать позволяет до поездки в медвежий угол -)
                                                                            • 0
                                                                              Беда в том, что мы не поняли, что это была чушь. Потому и не уточнили.
                                                                              • 0
                                                                                Допускаю, такое и со мой бывало, но не в таких масштабах конечно.

                                                                                Никто не застрахован -(
                                                                          • 0
                                                                            По-моему, тут все очень просто. Заказчик дает мутнейшее «ТЗ», обсуждаешь с ним подробности и детали, сам пишешь ТЗ (в идеале за деньги). Потом работаешь по прекрасно прописанному ТЗ.
                                                                            Все что не описано – все за доп. оплату.
                                                                            • 0
                                                                              И как? Часто получается так работать?
                                                                              • 0
                                                                                Вообще-то, так оно и делается. ТЗ пишет исполнитель обсуждая его с заказчиком. И да, за этот этап заказчик платит деньги. И насколько прекрасным получается ТЗ зависит от обоих сторон.
                                                                                • 0
                                                                                  Да, всегда, когда не хочется проблем.
                                                                                  • 0
                                                                                    А бывает так, что хочется проблем?

                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.