Без ТЗ: как разработчики в такое ввязываются



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



    Почему так происходит? Что можно сделать? Вот несколько версий:

    Версия 1: боюсь потерять клиента


    Всем знаком этот первобытный страх! Он достался нам в геноме от пещерных программистов! Если я упущу этого клиента, то мне нечего будет жрать!!! Возьмите себя в руки, председатель!

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

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

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

    Нужно понимать, что каждый заказчик немного мазохист, они любят когда с них требуют, отказывают им. В отношениях с заказчиком должен присутствовать едва уловимый BDSM. Если вы ведете себя в духе “что барин изволит?”, то возникают подозрения, а не менеджер ли вы?

    Версия 2: для друзей


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

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

    Вот, вам занимательная история одного проекта “по дружбе”. Моему близкому другу надо было срочно и недорого запускать интернет-магазин, потому как инвестор дал “добро”, и контейнер уже плыл из Китая. Я сразу предупредил, что это не совсем моя тема, так как я в основном работаю с корпоративными e-learning продуктами и медицинскими системами, но чего-нибудь придумаем. Итак, инвесторские деньги выделились, и друг проявился в моем поле зрения с бодрым: “Ну, давай портфолио по интернет-магазинам! Мы подрядчика выбираем! Только присылай побыстрее, не затягивай!” Я слегка фаломорфировал о того, как быстро “Спаси-помоги, друг дорогой!” трансформировалось в: “Я пришел к тебе с редкой возможностью поучаствовать в моем тендере!” и слил кореша с формулировкой: “У меня тут заказ на несколько миллионов — сорри, сейчас некогда портфолио по магазинам собирать”. Друг обиделся, но сообщил мне, что я “всё равно в шорт-листе”. На том и порешили.

    Версия 3: для себя


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

    А сколько можно делать правок! Когда логотип в шапке 18-й раз меняет свой размер на 2 пикселя, потому что “он всё ещё смотрится как-то непрофессионально”, вы начинаете чувствовать, что что-то пошло не так. Но оставьте сомнения! Вы же это не для клиента какого-нибудь, а для себя делаете! Так что не бойтесь еще раз 50 поменять концепцию — это точно поможет бизнесу! Вот почему часто внутренние проекты вполне успешных IT-компаний затягиваются на века.

    Версия 4: начинающий разработчик берусь за любой ад


    Легче всего охмурить юных нежных разработчиков, которые пламенно жаждут портфолио с крупными громкими проектами, открывающее любые двери. Но, как известно, без ТЗ получается ХЗ. А потому все это стыдно вообще кому-то показать, если конечно удастся дотянуть этот ужас до конца. “Вот, мы тут делали… И почти доделали! Оно не работает, но, в целом, видно суть”.

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

    Частенько портфолио собираются по принципу: “Мужик, ты на Drupal-е чего-нибудь собирал в этом году? Дай списать!” Клиенты — такие затейники, и часто их не устраивает “просто портфолио”. С меня как-то потребовали портфолио CRM для ТРЦ, чтобы подтвердить мою компетенцию в данной области.

    Версия 5: важный клиент


    Здесь так не принято. Мы никогда нигде и ни с кем так не работаем. Помните эксперимент, когда всех обезьян в клетке поливали ледяной водой, если одна из них покушалась на бананы на верхушке лестницы? Нарушительницу больно били, и за бананами никто не лез. Потом в клетку подсаживали новенькую, она лезла за бананами – тут же получала люлей, а потом уже сама мутузила очередную новенькую. Ученые по одной заменяли всех обезьян в клетке, и постепенно остались только приматы, которые ледяного душа в глаза не видели, но за бананы новеньких продолжали бить.

    Я это к чему? В крупных компаниях работают как раз такие обезьяны: «У нас в компании принято платить за финальный результат с отсрочкой платежа 60 дней!».

    Что ж, тогда остается только опросить разрабов, получить среднепотолочную оценку «этого», умножить ее на 3… нет, лучше на 5, и смело вписывать в КП. Купят – хорошо, не купят – и слава богу, потому что драть будут, как за Х10, всею вертикалью власти от младшего стажера до генерального.

    Конечно же, может найтись «свой хороший мальчик», который все сделает в два раза быстрее и дешевле. Надо встретить такого мальчика с позитивом, пообещать помочь советом, если что! А ближе к концу (предполагаемому) проекта позвонить и поинтересоваться: «Как дела?».

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

    Версия 6: неквалифицированные заказчики


    Допустим, приходит к вам что-то незамутненное с развесистыми ушами, считающее что программное обеспечение находят в капусте, прямо как детей.

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

    Версия 7: программист на зарплате


    Хорошая зарплата и кодить — это вторая по популярности мечта программиста после оплаты по часам. 250К, соцпакет и прямо в рай! И жизнь удалась! What a beautiful life! На самом деле, нет. Даже такие условия можно превратить в ад.

    Итак, приходит к разработчикам звезда пиара aka PR-менеджер и сообщает, что ей срочно-срочно надо поднять маааленький сайтик с регистрацией, мини-играми, начислением баллов за активности и магазином призов. Разработчик на зарплате любезно сообщает ей, что она должна скачать с GitHub стандартную форму ТЗ (содержащую, например, такие поля как “требуемый уровень безопасности данных пользователей” и “предполагаемый уровень пиковой нагрузки на сервер”), заполнить её и закоммитить обратно. Подробную инструкцию о том, что и как, она без труда найдет на корпоративной вике. Звезда пиара уходит, как обоссаный кот, но, в отличие от программиста-аутиста, она на то и звезда пиара, что умеет общаться с нужными людьми, поэтому начальнику отдела разработки прилетает по макушке, он достает наручники и пристегивает программиста к батарее на сутки-двое, пока тот не запустит маааленький и очень срочный промо-сайтик. А звезда пиара уже довольная бежит к нему с дизайном, который сделал гениальный маэстро из отдела медийной рекламы и который можно натянуть разве что на… Ну, вы поняли.

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

    Версия 8: лень, некому делать ТЗ


    “Я разработчик, и я не хочу писать ТЗ, я хочу алгоритм и копи-пейст!” Но почему бы не попросить клиента решить эту проблему? Аналитик вполне может быть на стороне клиента и выдать что-то вполне вменяемое.

    Если аналитика нет ни у клиента ни у вас, ну так наймите же его и выставьте клиенту счет!

    Версия 9: заказчик не знает как должно быть


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

    Бывает, что заказчик так и говорит: “Я не знаю, чего хочу — предложите варианты!” И очень хочется начать делать эти варианты, но надо взять себя в руки и составить ТЗ на варианты (да-да, варианты тоже должны делаться по ТЗ).

    Версия 10: ради будущих крутых проектов


    Когда я дописывал эту статью со своим прекрасным редактором, к нам пришел приятель и рассказал, что берется без ТЗ ради будущих проектов:

    — Сейчас возьмусь за копейки и без ТЗ, зато, потом они купят у меня мегапроект по нормальной цене!
    — Но почему?!
    — Я в это верю! И мне реально интересен этот проект!
    — Но почему они купят?
    — Аааа, не знаю! Ну, о-кей, вы меня застыдили! Я больше не буду так делать!

    Версия 11: “Я хочу, чтобы у вас глаза горели!”


    Бывают такие заказчики-искусители, шоу-мены, ораторы от бога, которые умудряются разжечь нехилый интерес к проекту даже у самого прожженного разраба с тленом в глазах. Я часто слышу именно такую фразу: “Я хочу, чтобы у вас глаза горели!” — и она сразу заставляет меня насторожиться. Часто подобные заказчики сопровождают свои речи щедрыми обещаниями доли в проекте или роли эксклюзивного оператора сверх-успешного продукта или сервиса. В общем, разработчик начинает верить, что делает проект для себя, а тогда зачем такие формальности, как ТЗ?

    Я безмерно уважаю людей с горящими глазами, но, пожалуйста, оставьте немного вашего сухого горючего на ТЗ!

    Вывод


    За всю мою деятельность отказ от ТЗ ни разу не помог упростить проект или заработок. Проблема в том, что в IT-проектах ТЗ пока не стало такой же обязательной частью подготовки. Как, скажем, в строительстве, где без проекта не рекомендуется строить даже деревенский сортир.

    Разработчики, ну пожалуйста, сделайте ТЗ отраслевым стандартом и научите клиентов, что иначе не бывает.

    PS: Не забываем писать в комменты почему и как вы взялись без ТЗ, кто вас к этому склонил, какие хитрости и уловки использовал.

    UPD:


    Тут пользователь сформулировал важные фундаментальные вопросы на тему «Что есть ТЗ? Что делает аналитик?», спасибо ему! habrahabr.ru/post/315624/#comment_9952198
    Спасибо всем комментаторам, благодаря им обсуждение получилось гораздо интереснее, чем сама статья.

    Only registered users can participate in poll. Log in, please.

    Мы работали без ТЗ!

    • 2.2%Я заказчик: был доволен19
    • 20.7%Я разработчик: был доволен175
    • 2.2%Я заказчик, был расстроен19
    • 74.8%Я разработчик: был расстроен631

    Как вас втянули работать без ТЗ?

    • 19.3%Версия 1: боюсь потерять клиента164
    • 21.1%Версия 2: для друзей179
    • 20.7%Версия 3: для себя176
    • 28.4%Версия 4: начинающий разработчик берусь за любой ад241
    • 18.0%Версия 5: важный клиент153
    • 31.0%Версия 6: неквалифицированные заказчики263
    • 44.3%Версия 7: программист на зарплате376
    • 27.6%Версия 8: лень, некому делать ТЗ234
    • 46.5%Версия 9: заказчик не знает как должно быть395
    • 12.1%Версия 10: ради будущих крутых проектов103
    • 6.7%Версия 11: “Я хочу, чтобы у вас глаза горели!”57
    • 5.4%Есть еще версия, напишу в комментах!46
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 212

      +15
      Что такое «работа без ТЗ»?
      Это когда заказчик сам не приносит готовое ТЗ? Ну так бывает в 99% случаев. И слава богу. Потому что когда приходят с готовым ТЗ — там такой АД, как правило…

      Нормальный workflow:
      Приходит заказчик. Расписывает чего хочет. Я составляю ему ТЗ(иногда бесплатно, иногда за деньги). После чего ТЗ утверждается и мы дальше спокойно работаем.

      Уверен, что большая часть проголосовавших за «Иногда работаю без ТЗ» — также делает — составляет ТЗ самостоятельно. А автор почему-то решил, что все поголовно делают «не знаю что, но надо сделать».
        +2
        «Я составляю ему ТЗ(иногда бесплатно, иногда за деньги). После чего ТЗ утверждается и мы дальше спокойно работаем.»

        Вы большой молодец, но так далеко не у всех происходит, к сожалению.
          +4
          ИМХО пару раз поработаешь без точного определения что нужно делать — и сам начнешь ТЗ составлять.
          Потому что переделки и хотелки заказчика нужно ограничивать, иначе они вылазят далеко за пределы срока и бюджета.
          Так что я уверен, что большинство так делает. Просто первоначальный опрос не раскрывает это.
            0
            Думаю вы просто сами умеете делать правильно и вам кажется, что иначе нельзя -)

            Далеко не все делают правильные выводы из сложившейся ситуации, и это не только разработки ПО касается.

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

            1. Набрасываю в обычном альбоме маркерами как я проект вижу.
            2. Отмечаю в том же альбоме какие-то моменты. на которые надо обратить внимание.
            3. Фотографирую этот альбом и отправляю руководителю проекта, чтобы он подготовился к моему визиту в общих чертах и договариваемся о встрече
            4. Вместе пишем ТЗ (от 15 минут до 2-х часов), дабы убедиться, что мы друг друга понимаем
            5. Мне присылают расчет на основе стоимости человеко-часа и, если всё норм, оплачиваю
            6. Работаем. Результат принимается примерно как у всех.

            В данном же случае мы, по моему мнению, без ТЗ работаем. Но работаем. И отлично, я считаю, работаем.
              +1
              Какой же это без ТЗ? O_o

              4. Вместе пишем ТЗ (от 15 минут до 2-х часов), дабы убедиться, что мы друг друга понимаем
                0
                Ну фундаментально я ж без ТЗ прихожу к исполнителю. И с исполнителем мы ТЗ составляем. Причем, не заморачиваемся на формальности и пишем ТЗ буквально «на пальцах». Но мы с исполнителем друг друга понимаем и проблем пока не было.

                Если это требует, кстати, дополнительной оплаты исполнителю — окей. Это ж как проект, ремонта, допустим, квартиры, или тюнинга машины: без плана работ нельзя. Тем более как без этого самого плана можно вообще предварительно посчитать стоимость работ? Я не знаю как. Но план работ и ТЗ — это, имхо, не совсем одно и то же.
                  +2
                  Когда работать начали Без ТЗ — так нехорошо
                  А когда потратили два часа на ТЗ и начали работать — так идеально

                  Вы и ваши разрабы все делаете правильно
                    0
                    > Вы и ваши разрабы все делаете правильно
                    Да, но судя по всему, вы сделали неверные суждения по прошлому голосованию.
                    А значит, вам нужно обновить статью: либо убрать критику таких «разработчиков»,
                    либо сделать апдейт, и указать, что «Как показал опрос в комментариях, понимание автора о ТЗ сильно отличается от понимания других разработчиков и заказчиков о ТЗ».
                      0
                      У меня пока не сложилось общей картины.
                      Вот в новом опросе 75% работало без ТЗ и расстроено.

                      Это те которые работали с ТЗ но которое казалось не ТЗ, или те, которые на словах о чем-то договорились?
              +4
              Не разводите демагогию!
              Без ТЗ это когда устно заказчик что-то рассказывает и показывает на пальцах. Через неделю всё забывает и надо переделывать потому что новый рассказ или «а я думал вы меня поняли» о совсем другом…
              Так же без ТЗ это когда формально ТЗ есть но заказчик на него не смотрит и всё еще продолжает устно вносить противоречащие самому себе правки в ходе разработки заставляя тем самым многократно верстать одно и тоже или переписывать один и тот же код под другую логику.

              То что вы написали это работа с ТЗ, только ТЗ вы делаете сами и утверждаете с заказчиком.
              А наличие ТЗ в первую очередь заставляет делать работу один раз, а не переделывать еще не сделанное много раз.
                0
                Вы похоже не внимательно читали(интересно ТЗ вы также внимательно читаете?).
                Я и говорю — что это фактически работа с ТЗ. Но, например, исполнители отвечали что работают без ТЗ, хотя фактически сами его делали, и по факту ответ не соответствовал действительности.
                Так что удосужтесь прочитать то, что комментируете.
                  –2
                  Мусьё, да вы пытаетесь меня затролить, не разводите демагогию ради демагогии!
                  У вашего комента больше всего ответов, вы видимо этого и добиваетесь.
                0
                И вот тут выходит косяк на стадии сдачи проекта. Выясняется, что когда заказчик что-то с вами описывал в ТЗ не учел еще целый ряд своих хотелок, и если вы начнете с ним аргументированно спорить и приводить в качестве довода, составленный вами же ТЗ, то боюсь заказчик будет думать, что его обманули. Конечно есть много способов урегулировать такой конфликт («и рыбку съесть и… в лодку сесть» ©), но осадочек может остаться.

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

                  Нужно ТЗ регулярно проговаривать, чтобы оно не забывалось.
                  Не 100% защита, конечно, но помогает.
                    0
                    Ну это рабочий момент.
                    Переговоры никто не отменял.
                    ТЗ — это способ объединить видение.
                    Доделки и хотелки — отдельная тема и обсуждается отдельно.
                    В зависимости от ситуации, иногда я хотелки/доделки делаю бесплатно, иногда за отдельную плату.
                    Всё сильно от ситуации зависит. Мне кажется особой связи с ТЗ тут нет.
                  +2
                  Нет самого интересного варианта. «Работаю на доверии». А уж как завоевать обоюдное доверие — это отдельный вопрос.
                    0
                    Доверие никак не связано с ТЗ.
                    У меня по большинству заказчиков «открытый договор». Акт о проделанной работе я сдавал последний раз лет 5 назад. Но при этом со всеми заказчиками есть ТЗ.
                      0
                      На мой взгляд, проектирование не отделимо от программирования. Обе фазы чередуются в процессе разработки. Поэтому я и не выделяю этап составления ТЗ.

                      Мне приходилось иметь дело с оформлением по ГОСТу, польза от потраченного времени была исчезающей. Вот без этого формального подготовительного процесса я предпочитаю обходиться.
                    +1
                    А заказчик вам платит за ТЗ? Или как вы договариваетесь, если он, в итоге, не закажет, например. Вот, для меня это самая большая проблема, например: куча работы по исследованиям проблемы и пресейлзу, а потом заказчик пропадает.
                      0
                      Для очень жирных проектов — это абсолютно нормально.

                      Да, можно пресейлз и месяц делать. Да, кто-то сливается.
                      А те, кто не сливаются — платят 100500 * 100500 * 100500 денег, что все компенсирует.

                      В мелких проектах пресейлз и ТЗ на 1 час? Это вообще не затраты.

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

                      Обычно заказчик примерно знает, чего он хочет (очень примерно), на основании детального допроса делается общий план сверху и детальное представление о том, что делать, на итерацию (1-2 недели). Все целиком сразу и подробно расписывать смысла нет, потому что он еще передумает сто раз, и это нормально. Как расписывается итерация — зависит от достигнутого уровня взаимопонимания: сначала, пока друг в друге не уверены, можно и приложение к договору расписать, а со временем и увеличением взаимопонимания и доверия уже хватает логов чата и зарисовок на салфетке. Обычно удобнее всего мокапы с комментариями.
                        +1
                        ТЗ — это то, что позволяет однозначно ответить на вопрос: соответствует результат ожиданиям или нет.
                        А уж его форма и содержание — дело десятое.
                          0
                          А тут дело тогда не в ТЗ, а в том, чтобы четко понять задачу и убедиться, что понимание соответствует тому, что в голове у заказчика. А уж как это фиксировать — зависит от множества факторов.
                            0
                            ТЗ — это и есть фиксация задачи.
                            Или в чем еще вы видите его суть?
                              +4
                              А по-всякому бывает. Часто суть в том, чтобы прикрыть свою задницу.

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

                                Неоднократно.
                                  0
                                  А я считаю вы правы по поводу однозначности.

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

                                  Причем по ходу прочтения таких историй становится понятно, что исчерпывающее ТЗ на копирование файла, даже если оно будет огромным просто невозможно.

                                  В целом ТЗ это скорее ориентир, а не однозначный ответ на вопрос, к сожалению.
                                0
                                Есть ПЗ (постановка задачи) и есть ТЗ. Как пример

                                ПЗ — ускорить работу программы минимум на 30 процентов.

                                ТЗ… теоретически там должно быть написано на сколько мы ускоряем каждый из этапов разработки и за счет чего (расход памяти, улучшенные алгоритмы...),… Практически, пока весь код не прочел — это непонятно.

                                Поэтому на таких задачах — работаем без ТЗ,

                                  0
                                  А вы видели это ГОСТ-34 из замшелых 80-х годов?
                                    0
                                    последний раз в ВУЗе работал по этому госту, но уже тогда все забивали и срезали углы.
                                      0
                                      Видел немного, ага. Оттуда и некоторая ирония.
                                    +9
                                    В чем проблема работать без ТЗ по Agile при T&M-схеме оплаты?
                                      –3
                                      В выгорании
                                        0
                                        Увы, но чудес не бывает даже в Agile. :)
                                        У вас есть Story клиента, как минимум. У вас есть планирование, как минимум.
                                        На этих двух этапах вы и делаете «магию» ТЗ — что надо сделать и как. что уже подразумевает явную связку «Ожидания Клиента» — «Сделаем Так».
                                        Если клиенту процесс разработки не подходит, то меняется процесс или клиент.
                                          0

                                          По мне так идеальная схема для всех.


                                          Заказчик не хочет писать ТЗ — не пишет ТЗ.
                                          Разраб хочет денег — любые переделки/доделки оплачиваются.

                                          +6
                                          а где «программа нужна вчера, а писать тз — неделя»?
                                            +1
                                            Думали в этом направлении. По опыту все-таки ТЗ тут экономит время и все ускоряет. Правда-правда.

                                            Хотя аргумент такой заказчики используют, вы правы.
                                              +2
                                              Простенькой ТЗ пишется за несколько часов. И всё равно нужно структурировать понимание. Проще всего совмещать — пишем ТХ параллельно с этим формируем видение проекта.
                                                0
                                                Поддерживаю. Даже простенькое ТЗ лучше чем без него.
                                                0
                                                «Воспоминания» заказчкика о том, как должен выглядеть и работать результат порой могут меняться по несколько раз на дню.
                                                Без фиксации договоренностей, вы выйдете в бесконечный «agile». И или растянете сроки, или бюджет, или получите недовольного результатом заказчика.
                                                А фиксация в итоге приведет вас к ТЗ. И это справедливо даже для «микро-проектов», которые вы можете сделать за 1 день, пусть даже в виде ТЗ будет выступать некое письмо заказчика и ваш ответ с перечислением фич к реализации.
                                                  0
                                                  Agile оплачивается все это время…
                                                  ;)
                                                    0
                                                    «Любой каприз за ваши деньги», к сожалению имеет и обратную сторону., как я уже писал выше «растянете сроки, или бюджет, или получите недовольного результатом заказчика». В результате страдает ваша репутация.
                                                    Гораздо правильнее убедить заказчика и сделать то, что ему действительно нужно. Конечно на это часто требуется потратить уйму сил и ресурсов, но ваша карма и репутация несомненно будет в плюсе. А у заказчика, которого вы убедили сделать по вашему и сделали все хорошо будет для вас большой кредит доверия как в рамках разработки, так и в рамках принятия решений.
                                                    Более того, если вы в результате не договорились и разошлись. А заказчик нашел более сговорчивого по сценарию «Любой каприз за ваши деньги», после попадания на сроки/деньги/результат, ваши мудрые слова вспомнят и опять же ваш рейтинг повысится :)
                                                0
                                                Считаю, что ТЗ нужно составлять не из соображений «иди мне и распиши как надо», а из соображений «чувак, над твоим проектом придется работать, долго работать, ОЧЕНЬ ДОЛГО работать, ты хотя бы составь ТЗ, чтобы понять насколько это сложно, а потом будем обсуждать оплату».

                                                Обычно «маленький сайтик с регистрацией, начислением баллов, магазином сувениров и регистрацией» предполагается как штука, которую подобно кролику достали из шляпы (актуально: «возьмите готовое решение, вон их сколько»), попытка объяснить, что это все придется делать, причем заново, заканчивается в лучшем случае обвинением в непрофессионализме, в худшем — «я сюда не поговорить пришел, а найти профессионала, мои деньги стоят для меня очень дорого, не хочешь ты, найдем другого лоха».

                                                А вот когда он сам составит ТЗ — ему наверное больно узнавать, что мне его ТЗ ни в болт не впилось, но это необходимая точка сортировки клиентов — если он «смог» составить ТЗ, значит он понимает, за что и почему он платит.
                                                  +3
                                                  Хорошо наверное жить в Ривенделле, где хороших заказчиков хватает на всех, надо только чуть-чуть поискать.
                                                  В Мордоре же, где 95% исполнителей работают без ТЗ, а 4% с бюджетами минимум от 10 миллионов, быть в оставшемся 1% крайне непросто.
                                                  Если бюджет большой, то ваша компания из 10 человек «слишком мелкая», а если не большой, то клиент скажет «а какое ТЗ, уйду ка я прямо щас к конкурентам».

                                                    0
                                                    Мне как раз говорят: как хорошо, что все с ТЗ. Конкуренты обещали: «все сделаем в лучшем виде», а вы вопросы задаете, какие молодцы.
                                                      +1
                                                      Еще ни разу в жизни мне не попадался бы клиент, который бы отказался работать по составленному мной для его проекта ТЗ.
                                                        0
                                                        Зато у меня встречался тот, который пока я составляю ТЗ заказывает у того, кто «больше сотрудников в штате имеет», или просто «у друга»
                                                        Сложность не составить ТЗ, а упросить его начать работать с тобой, пока у тебя еще нет ТЗ
                                                          +2
                                                          Заказчики иногда уходят. Это нормально.
                                                            0
                                                            А надо чтобы он участвовал в создании ТЗ и включился в работу в месте с вами.
                                                            И лучше конечно, чтобы оплатил ТЗ, это тоже привязывает и заставляет более серьезно подойти к утверждению.
                                                              0
                                                              Я на старте оговариваю стоимость ис роки составления ТЗ. Если клиент новый — предоплата ТЗ 100%. Если проект стартует, то стоимость ТЗ списывается со стоимости заказа.
                                                              +1
                                                              Мне попадался: «Мы не можем ничего согласовать, так как это отрежет нам дорогу к изменениям».
                                                              Или: «Мы не можем согласовать, т.к. не знаем как должно быть, но начинать надо сейчас»
                                                                0
                                                                А можно поподробнее?
                                                                Эти байки были бы весьма интересны.
                                                                  0
                                                                  Ну если подробно начну рассказывать, спалюсь -)
                                                                  В крупных компаниях это норма, т.к. сроки пролюбили, а согласовывать нужно с несколькими подразделениями.
                                                                  Довольно типичная ситуация.
                                                                    0
                                                                    Согласовали сроки и сумму?
                                                                  +2
                                                                  Это еще ничего.

                                                                  Мне попадался совсем забавный кадр. Прислал email с описанием, чего он хочет (это был первый контакт, до этого не общались). На следующий день, когда я с ним связался, чтобы обсудить возможное сотрудничество, он спросил — «как, а что, вы еще не начали делать? Почему?»
                                                                    0
                                                                    А каков был масштаб проекта?
                                                                    Может там на полчаса работы?
                                                                      0
                                                                      Интеграция с федеральными серверами государственными, как вам? -)
                                                                        0
                                                                        Выяснить не успел, но если предположить минимально возможную реализацию того, что было в емейле, то недели три.
                                                                        0
                                                                        Ааа точно. У меня такие есть постоянные.
                                                                        Я в конце каждого письма и каждого разговора поясняю, что пока ничего делать не начали.
                                                                        Чтобы, не было таких звонков через месяц в духе «почему задерживаете?»
                                                                        0
                                                                        Мне попадался: «Мы не можем ничего согласовать, так как это отрежет нам дорогу к изменениям».
                                                                        Или: «Мы не можем согласовать, т.к. не знаем как должно быть, но начинать надо сейчас»

                                                                        Слова Agile, Scrum, Kanban и т.д. летят из каждого утюга уже лет 7… Как они смогли пролететь мимо Вас?
                                                                        Это всё именно для таких заказчиков и придумано. Можно конечно условно сказать, что у вас есть некое подобие ТЗ на ближайшие 2 недели, но по факту это явно пункт "работаю без ТЗ", т.к. ТЗ на весь проект не пишется.

                                                                          0
                                                                          1. По Agile и Scrum работаю
                                                                          2. ТЗ на весь проект избегаю писать, пишу на первый маленький этап

                                                                          Как по Agile и Scrum прогнозировать бюджеты и сроки мне так и не стало понятно.
                                                                          Как делаете вы, при условии, что клиент не согласен выкупить время например 5-ти разработчиков на непредсказуемое количество дней, пока проект не будет сделан?
                                                                            0

                                                                            В моём понимании ТЗ — это официальный документ, подписанный с двух сторон, с описанием в том числе и мелких деталей. План итерации — это скорее неподписанный каркас для "мини-ТЗ".


                                                                            Как делаете вы, при условии, что клиент не согласен выкупить время например 5-ти разработчиков на непредсказуемое количество дней, пока проект не будет сделан?

                                                                            Не работаем с ним :-)
                                                                            Тут в принципе выбор: либо вы работаете по водопаду (и сами себе буратино), либо штампуете типовые проектики, либо у вас неизвестный бюджет и сроки. Можно давать клиенту пробный период 2-3 месяца, если он раньше не работал по такой схеме, прежде чем какие-то долгосрочные договора заключать.
                                                                            Важно, что при Agile вы должны даже за этот короткий срок выдать что-то работающее. Имхо, абсолютная противоположность ТЗ-подходу.

                                                                              0
                                                                              Эмм ну у меня мини-этапы подписанные делятся от недели до месяца (иногда до двух). И клиент получает что-то работающее по опыту через неделю-две.
                                                                              Стараемся каждую неделю выпускать демонстрации.

                                                                              А что вы делаете, если у вас 5 разрабов на Agile пилят проект, а потом у клиента наступает внутреннее согласование с глобалами месяца на полтора два, ато и на 3-4.
                                                                              Или же просто пауза на 15 дней пока данные необходимые на стороне клиента подготовят, или инфраструктуру (которую вы не можете у себя продублировать), или ждем ответа из глобального IT-суппорта по недокументированным глюкам в API.

                                                                              1. Что делают в это время 5 разрабов?
                                                                              2. Если они простаивают, кто им платит за простой?
                                                                              3. С потоком внезапных, срочных, и важных тикетов на суппорт (т.е. очевидно, что 100% ваша вина, а не клиента) по прошлым проектам, которые отвлекают команду от текущего спринта что делаете?
                                                                                0
                                                                                Эмм ну у меня мини-этапы подписанные делятся от недели до месяца (иногда до двух).

                                                                                И Вы их прям как ТЗ детально расписываете? Имхо, какая-то излишняя бюрократия, зря время отнимающая. Но если клиенту нравится такой подход, то ok.


                                                                                И клиент получает что-то работающее по опыту через неделю-две.

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


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


                                                                                С потоком внезапных, срочных, и важных тикетов на суппорт по прошлым проектам

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

                                                                                  0
                                                                                  У меня блочное ТЗ.
                                                                                  -Каждый блок — пользовательский сценарий.
                                                                                  -К каждому блоку есть список экранов.

                                                                                  Клиент понимает сценарий, разработчики понимают сценарий.
                                                                                  Дальше эти блоки встают в таскменеджер и все едет.

                                                                                  Иногда клиент думает несколько месяцев и появляется до 7 версий этого короткого ТЗ.

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

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

                                                                                    Имхо, это не по ТЗ, это BDD называется :-)


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

                                                                                    У вас просто какая-то особая специфика.


                                                                                    Ну а вот выделенный человек он разработчик и сидит вкуривает в старые проекты?

                                                                                    Программист.

                                                                      0
                                                                      а если не большой, то клиент скажет «а какое ТЗ, уйду ка я прямо щас к конкурентам».


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

                                                                      Скорее стремятся уйти те, кто только начинающие,
                                                                      а они еще не знают сколько стоит разработка ПО («сколько-сколько стоит эта ерунда»)

                                                                      или, напротив, для которых стоимость значения не имеет,
                                                                      а имеет значение собственный комфорт
                                                                      (заняты, доверяют вкусу разработчика).

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

                                                                        0
                                                                        Так просто в Мордоре опытный заказчик — зверь редкий, в основном залётный. Если этого страшного слова не пугается, то первый, к кому он приходит, вцепляется мёртвой хваткой, лишь бы к «колегам по цеху» случайно не забрёл.
                                                                        А так по схеме " умножая стоимость" все и работают. Зато навык прорицания прокачивается до такой степени, что уровень хаоса в предстоящем проекте угадывается по первым телефонным гудкам :)
                                                                          +1
                                                                          Я тебя умоляю… так ровно во всем остальном мире.
                                                                          Там задачки, сформулированные в виде «Хочу свой Фейсбук» даже чаще встречаются.
                                                                            0
                                                                            Ну вот мы и выяснили, в какой из означенных стран находится реальный мир :)
                                                                      0
                                                                      Версия 12: Работаю без ТЗ, потому-что сам его составляю вместе с заказчиком.
                                                                      При этом понимаю заказчика с полуслова. Плюс советую заказчику от чего отказаться, а это лучше сделать вот так.
                                                                      И так продолжается уже много лет, все стороны очень довольны. В прошлом голосовании голосовал как «работаю без ТЗ», потому-что действительно работаю не для выполнения ТЗ, а для решения проблемы заказчика. И да, у нас доверительные отношения, поэтому сразу несколько пунктов сливаются в один.
                                                                        0
                                                                        Эмм ну статья не про вас тогда, у вас все идеально -)

                                                                        Это с ТЗ и так и должно быть в идеале!
                                                                        +2
                                                                        Я разработчик десктопного и мобильного софта в продуктовой компании из меньше чем 10 человек. ТЗ в глаза не видел :) Есть успешно работающий продукт, которые продаётся; есть product owner с видением дальнейшего развития проекта, есть пользователи, которые присылают пожелания, и есть баг-трекер. Больше, вроде, ничего не требуется.
                                                                          0
                                                                          О! Как хорошо, что вы появились.

                                                                          Вы с нуля прямо взялись, или просто патчи пишите?
                                                                          В каком виде вам задачи формулируются? Есть ли таск-трэкер?
                                                                            0
                                                                            Над кокретно моим проектом работал один человек, 5 лет назад взяли меня в помощь, мы вдвоём с нуля написали важную функциональность. С тех пор лично я примерно половину проекта переписал — если не с нуля, то как минимум причесал код. Пару лет назад начал помогать и на другом проекте, «флагманском» продукте компании, который, кроме меня, 1.5 человека делают.

                                                                            Задачи формулируются чаще устно, иногда в виде тасков/багрепортов в Jira. Но в целом багтрекером пользуемся редко. Я туда записываю только ошибки, о которых сразу понимаю, что исправим нескоро. Если примерно понимаю, как исправить — сразу беру и делаю.
                                                                              0
                                                                              Ну все-таки жира есть.

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

                                                                              Не понимаю как вы устно вообще можете работать!
                                                                                0
                                                                                Мне каждый день вываливается такой лист, что его невозможно просто в голове удержать


                                                                                Если вы именно бизнес-аналитик, как написано в вашем профиле — то это и есть основная часть вашей работы.

                                                                                Для разработчика же работа с требованиями важная, но не самая большая часть работы.

                                                                                Так что все логично.
                                                                                  0
                                                                                  У разработчиков текущие задачи в голове тоже плохо умещаются -)
                                                                                  0
                                                                                  Если жира отвалится, заметим месяца через 3, не раньше. И бизнес никак не пострадает, в принципе :)

                                                                                  Думаю, секрет ненапряжной работы №1 — обозримый размер проекта. Если весь проект понимаешь и хорошо ориентируешься, то и всё, что с ним связано, тоже понимать легко. На большем проекте работать не хотел бы. Мне нравится, что я могу сдесь сделать практически всё, что угодно. А быть винтиком в машине, ковырять всё время какой-то один модуль — фу.

                                                                                  У меня бывали «завалы», когда за 1-2 дня приходило много багрепортов. Я просто открывал файлик TODO.txt и записывал, чтоб не забыть. За пару дней всё делал. А уж если что-то не могу сделать (например, сложность задачи несообразна выгоде), то записываю в Jira «на потом», понимая, что потом, вероятно, никогда не наступит.
                                                                              0
                                                                              backlog же есть небось
                                                                              +2
                                                                              Да запросто.

                                                                              Клиент, с которым я знаком уже 5 лет.
                                                                              Планы чего он хочет мы с ним оговорили на месяцы вперед.

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

                                                                              Никаких рисков.

                                                                              ТЗ в этом случае — излишние расходы.
                                                                                0
                                                                                Т.е. все договоренности только на словах?
                                                                                Никак вообще ничего не формализовано?
                                                                                  +1
                                                                                  Не-а.

                                                                                  Иногда он мне письма пишет с теми вещами которые в памяти не укладываются.

                                                                                  Буквально по паре предложений раз в неделю.

                                                                                  И это не мелкие работки.
                                                                                  За 5 лет только он один мне купил уже 2 автомобиля.
                                                                                0
                                                                                В большинстве случаев на моей практике требование с заказчика ТЗ означает желание разработчика снять с себя ответственность за принятые им же технические решения. Заказчик, как правило, не обладает достаточной технической экспертизой, чтобы не то чтобы составить, а даже понять нормальное ТЗ. Для работы с таким заказчиком для уменьшения числа конфликтных ситуаций лучше работать со списками функциональных и нефункциональных требований, сценариев использования, тесткейсов и т. п. на языке предметной области и понятных заказчику терминов UI, пряча от него всю техническую кухню, кроме тех технических требований, с которым он пришёл сам и тех, которые будут определять среду исполнения разрабатываемой системы: ОС, рантайм, готовые сервисы типа СУБД и веб-серверов…
                                                                                  +1
                                                                                  Компетенцией же.

                                                                                  Экспертиза — это неуместная калька с английского. В английском слово экспертиза как раз и означает «опыт, компетенцию». А в русском языке слово экспертиза означает «исследование с целью дать оценку».
                                                                                • UFO just landed and posted this here
                                                                                    0
                                                                                    Программист на зарплате (версия 7). Прямо сейчас работаю над задачей для бухгалтерии. Бухгалтерия это особая каста в нашей компании, так сказать «приоритет номер ноль» (версия 5). Писать ТЗ бухи просто не в состоянии, объяснять тоже (версия 6, 8 и 9).
                                                                                    Делать надо срочно, без ТЗ и без внятного объяснения. Спасает лишь опыт и капелька магии.
                                                                                      0
                                                                                      1С что ли?
                                                                                      Я работал 1С-ком довольно долго.

                                                                                      И с вами не соглашусь.
                                                                                      Нужно с бухгалтерами правильно побеседовать — и они вам все расскажут и по полочкам разложат.

                                                                                        0
                                                                                        Нет, «Задницей Одина» я не занимаюсь. Данная конкретная задача из области биллинга.
                                                                                          0
                                                                                          Бухгалтера — гораздо более адекватные люди, чем средние сотрудники.
                                                                                          А выбить сначала из заказавшего детали задачи — ваша прямая обязанность.
                                                                                      0
                                                                                      Нет в голосовалке варианта — Я аналитик и вообще не понимаю этих людей, как они работают без ТЗ:)
                                                                                        0

                                                                                        То с чем приходил заказчик, обычно не читал даже сам заказчик. А то что писали совместно не читали программисты, потому что "вроде и так было понятно". В итоге спасали только спринты и демо. Проекты не большие на 2-3 месяца на 3 программистов, думаю дело в этом. В сроки и в бюджет влезали.

                                                                                          +1
                                                                                          Менеджер очень торопился срубить бабла, и отдал клиенту договор на подпись. А про ТЗ тупо забыл, хотя оно было готово.
                                                                                            0
                                                                                            Пишу CRM для управляющей компании с несколькими подразделениями с немного разными, но смежными сферами деятельности. ТЗ были когда-то написаны со слов, тогда еще, заказчика и утверждены. Но спустя примерно год появились новые требования, которые ломают, казалось бы, продуманную структуру некоторых компонентов всей системы. Сейчас работаю без ТЗ, но раз в неделю провожу встречи с руководством, где мы обсуждаем возникшие проблемы и составляем дальнейший план действий по их разрешению, чтобы не плодить костыли и безболезненно внедрять новшества. Пока получается.
                                                                                              0
                                                                                              Работаю без ТЗ постоянно (интернет магазины и прочие мелкие проекты) применяя вместо него принцип «Каши из топора».
                                                                                              Продаю сначала клиенту недорого некоторый оговоренный с ним крайне базовый функционал(движок трех-страничник) плюс типовой дизайн с правом поменять его один раз (тщательно описав что именно он хочет изменить). Все что сверх него — за отдельную плату.
                                                                                              Проблемы с нарастающими хотелками заказчиков решаются очень просто — введением отдельной платы за каждую отдельно взятую хотелку. При большом количестве изначальных хотелок, отличающихся от базового функционала, работаю на окладе.
                                                                                                0

                                                                                                Я вот в реальной жизни ни разу не встречал ТЗ, за ~9 лет работы. Правда я обычно не фрилансю, а работаю на какую-нибудь одну компанию над собственными проектами.

                                                                                                  0
                                                                                                  А как же вам задачи ставят? Устно?

                                                                                                  Как работу принимают?
                                                                                                    0

                                                                                                    Зависит от компании (за 9 лет поменял несколько). Были таск-трекеры, но чаще всего это устно/email/skype и т.д.


                                                                                                    В лучшем случае – есть описание фичи + нарисованный дизайн (работаю, в основном, по фронтенду) или готовое API, которое надо прикрутить. На последнем месте (2.5 года, удалёнка с почасовой ставкой) – чаще всего просто краткое описание конечной цели.


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


                                                                                                    "Как принимают" – по принципу "работает ли нужная фича". :-)

                                                                                                      0
                                                                                                      Но все-таки какое-то письменное задание на задачу всегда присутствует?
                                                                                                        0

                                                                                                        Ну, если считать "письменным заданием" сообщение в мессенджере или email – то да. А детали, при необходимости, мне надо уточнять самому (если что-то не ясно или возможны разные варианты).

                                                                                                  0
                                                                                                  в моем случае вариант «9 — заказчик не знает как должно быть» еще расширяется тем, что он не знает как вообще может быть (т.е. когда я после презентации очередной части говорю «а тут я еще вот так сделал» у них обычно круглые глаза и вопрос «а что, можно и так? » :) ) + у заказчика еще есть начальство, которое тоже не знает как оно должно работать + конечные пользователи, которые могут сказать только как ПО ДРУГОМУ это должно работать :)
                                                                                                  т.е. процесс такой — поверхностные требования — лепка работающего прототипа — презентация — сбор изменений (а по сути настоящих требований) и очень часто уже поздно писать ТЗ, т.к. сделать быстрее… (это вот наверное упомянутая в другом варианте лень), но если решение сложное — то технический док таки создается… потом… :)
                                                                                                    0
                                                                                                    в моем случае вариант «9 — заказчик не знает как должно быть» еще расширяется тем, что он не знает как вообще может быть (т.е. когда я после презентации очередной части говорю «а тут я еще вот так сделал» у них обычно круглые глаза и вопрос «а что, можно и так? » :) )


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

                                                                                                    Ты и сам, когда обращаешься к специалисту за услугами в сфере, в которой ты не в зуб ногой — будешь только рад, если он тебе расскажет, а что вообще можно тут делать…
                                                                                                    0
                                                                                                    Хороший текст. Спасибо. Отвлёкся от работы минут на 15-ть =)
                                                                                                      +1
                                                                                                      А я на 20-вадцать =)
                                                                                                      0
                                                                                                      Добавлю МОЩНОСТИ в пункт 1.

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

                                                                                                      Итог:
                                                                                                      Конкурент может потерять время и вообще ничего не заработать! — 50% / 50%
                                                                                                      Ты — имеешь больше вероятность заработать и меньше парится — 90% / 10%

                                                                                                      Имеет смысл для конкурентной борьбы.
                                                                                                        0
                                                                                                        Ещё версия: в начале ТЗ было, но потом как-бы нет. ТЗ это основа, а дальше всё начинает меняться, и дорабатывать полноценное ТЗ уже не стали, просто отказались от него, когда старое себя изжило (часть реализовали/часть передумали). Стори есть, таски есть, но чёткого видение конечного продукта уже ни у кого нет, тем более, что его нет на бумаге.
                                                                                                          0
                                                                                                          это бич и печаль, часто сталкиваюсь тоже -(
                                                                                                          0
                                                                                                          Какой-то мир розовых пони, где заказчики знают чего хотят, осознают свои ошибки и принимают на себя вину, готовы быстро согласовать необходимые документы и в срок платят, даже если то, что получилось совсем не то, что нужно но соответствует тз, да и еще без проблем готовы примерно 1/3 заплатить за обследование и составление тз( а то и половину и вперед без гарантии результата ).
                                                                                                          Часто наблюдаю работу небольшими итерациями, без ТЗ но с приблизительным описание результата( без формального документооборота, например по email ).
                                                                                                            +1
                                                                                                            Этот «розовый мир» у вас будет до первой судебной разборки, до первой разборки «ты сделал не то что мы хотели».
                                                                                                            До первой разборки типа:
                                                                                                            — ты сломал, что уже работало!
                                                                                                            — Но вы же сами в этой итерации заказали такую фичу. А она вступила в коллизию с прошлогодней.
                                                                                                            — а ты чего не сказал?
                                                                                                            — а я думал вы подумали и осознанно заказали.
                                                                                                            — возвращай все в зад… денег не будет…

                                                                                                            Все рано и поздно приходят к нормальному вменяемому ТЗ.
                                                                                                            Вопрос его создания и управления им — это другая и интересная тема :)
                                                                                                              0
                                                                                                              Чтобы судебную разборку учинить какой то документ о взаимных обязанностях иметь надо… например ТЗ.
                                                                                                              а для разборки «ты сделал не то что мы хотели» какой то документ в котором они пишут что именно они хотели, причем так, что это не допускает толкования по которому вы все сделали. Так что на мой взгляд nApoBo3 таки прав- небольшие итерации с согласованием по email — это наше все.
                                                                                                            0
                                                                                                            Вместо ТЗ — User story. Часть от клиентов, часть сам завожу. Для больших изменений завожу RFC и рассылаю тем, чьи комvентарии могут быть полезными. На основе RFC рисуются change requests.
                                                                                                              +1
                                                                                                              Пишу ТЗ с 2009 года =) Были проекты, в которых написание ТЗ потопило проект (пока написали, утвердили со всеми, поменялось законодательство и другие правила игры). Были проекты, в которых концепт, полученный «на коленке» в процессе переговоров на первой встрече (не написание ТЗ), в процессе сильно отличался от необходимого решения и сей момент тоже потопил проект.

                                                                                                              А вывод один и как везде: важен компромисс в % потраченного времени на разжевывание ТЗ по отношению к его реализацию (этапов больше, два для простоты). Вопрос должен звучать не «Надо ТЗ или нет?», а «В конкретном проекте какую степень детализации мы себе можем позволить для победы». Некоторые задачи понятны с первого взгляда (исправление очевидных багов, например). А некоторые требует проработку ТЗ на всех эшелонах: vision, спецификация функциональных, спецификация нефункциональных, спецификация системных требований, план внедрения и тд тп.
                                                                                                              Эмпирически мы на подсознательном уровне понимаем, какую степень проработки ТЗ в своих проектах применять (ТЗ как… опаприкрывательство, как план для клиента, разработчика, тестировщика, внедренца и тд). Но общих правил тут наверное нет.
                                                                                                                0
                                                                                                                Были проекты, в которых написание ТЗ потопило проект (пока написали, утвердили со всеми, поменялось законодательство и другие правила игры)

                                                                                                                Как раз оно спасло проект :)
                                                                                                                Сначала бы просадили бабло на реализацию, а потом все равно пришлось бы переделывать :) Судя по потраченным срокам на ТЗ окупиться бы не успел проект :)

                                                                                                                Со степень детализации — это верно.
                                                                                                                  0
                                                                                                                  Ну я немного не довел суть истории. Можно год писать ТЗ на реализацию, просто к моменту окончания — мир поменялся и пиши снова. А в реальности надо MVP как можно раньше выпустить, в процессе получать обратную связь как можно раньше(ну и иметь серьезных прогеров/архитекторов для требуемой гибкости продукта). Т.е. этот год, ну 10 месяцев, можно иметь некий продукт с выхлопом пользы для заказчика и постепенным наращиванием «мяса».
                                                                                                                    0
                                                                                                                    Это не вопрос ТЗ. Это вопрос выбора метологии выполнения проекта.
                                                                                                                    То, что вы описали в «пессимистичном случае» — это классический недостаток водопада.
                                                                                                                    То, что вы описали в «оптимистичнос случае» — это классическое достоиство Agile методологий.
                                                                                                                    Что служит выбором между методологиями? тоже что и всегда: время-ресурсы-деньги.
                                                                                                                    Но ни одна из этих метологий не исключает ТЗ. Просто она перепихивает их на разных участниках. И всегда! присутсвует связка — Хотелка-Приемка. Даже в врырожденном случае «без ТЗ» экстремального программирования — у вас будут карточки, а за спиной стоять «носитель знания» который тут-же показывает «пальцем» как сделать или поправить (причем риски накосячить лежат полностью на «носителе знания»).
                                                                                                                    Считайте что РИСК + ТЗ =100% Увеличив одно, вы понимажете другое.
                                                                                                                      0
                                                                                                                      На всякий случай скажу, что у меня все оке, все схвачено и нет проблем на этом поприще =) Зашел так сказать точку зрения высказать.
                                                                                                                      Человека из топика разоряется, что «Как так, почему без ТЗ существует разработка». А на самом деле ТЗ ведь не цель, главное результат. Есть результат при минимуме рисков — молодцы. И не важно, было отдельное ТЗ и этап его построения до начала проекта или нет.
                                                                                                                        0
                                                                                                                        У меня тоже были ситуации, когда «весь пар ушел в свисток»: писали ТЗ пол года, а за проект так и не взялись. Так бывает к сожалению.
                                                                                                                +1

                                                                                                                Своя версия: Без ТЗ за долю в проекте. После этого ТЗ как правило всё равно появляется.

                                                                                                                  0
                                                                                                                  И как выстрелила доля хоть раз?
                                                                                                                    +1

                                                                                                                    Пока что нет :)

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

                                                                                                                      Как заказчик работал с ТЗ и очень грустил.
                                                                                                                      Вписать в ТЗ требование к качеству кода или тестированию фактически невозможно.
                                                                                                                      Если делать деспотично — будет плохой код или недостаточная полнота тестирования, акт не подпишем, пока не переделаете за свои средства — то найти подрядчика практически нереально.

                                                                                                                      Если в рекомендательном плане, то кончается всегда одним и тем же:
                                                                                                                      — У вас тут костыли и велосипеды, код будет трудно поддерживать, можно было сделать эффективней и короче.
                                                                                                                      — Это всё субъективно.
                                                                                                                      — Но PEP8 можно же было хотя бы во внешних интерфесах соблюдать? Мы ж просили.
                                                                                                                      — Требования соблюдены — подписывайте акт. А на рекомендации мы клали с прибором.
                                                                                                                      — Всё протестировали?
                                                                                                                      — Конечно.
                                                                                                                      — Вот на таком простом тесте у вас возникает исключение.
                                                                                                                      — В реальности такого не будет, но если очень надо, за отдельную плату можем и этот синтетический тест приобщить.

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

                                                                                                                      Как исполнитель работал с ТЗ, расстроен.
                                                                                                                      ТЗ писали тратя свои силы, пытаясь угадать, что хочет заказчик. Проще был бы сразу код писать и переделывать по результатам отзыва.
                                                                                                                      ТЗ пришлось переписывать несколько раз за контракт (контракт такую возможность предусматривал), но…верёвочки рвались разные, а Пяточёк было один и тот же. Очень трудно вписать в ТЗ накладные расходы, связанные с отладкой стенда заказчки; штрафы за простой, пока заказчик правит свою сторону, в случае «хороших отношений» вписать просто невозможно.

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

                                                                                                                        0
                                                                                                                        Вписать в ТЗ требование к качеству кода или тестированию фактически невозможно.

                                                                                                                        А в чем проблема? включите в договор не только передачу решения, но и тестовых сценариев и протоколов тестирования.
                                                                                                                        Есть инструменты по оценке кода. Если вам это надо — просите протоколы :)
                                                                                                                        Только будьте готовы оплатить это :) Любой каприз за ваши деньги :)

                                                                                                                        А на рекомендации мы клали с прибором

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

                                                                                                                        то найти подрядчика практически нереально.
                                                                                                                        велкам :))

                                                                                                                        ТЗ писали тратя свои силы, пытаясь угадать, что хочет заказчик.

                                                                                                                        Забавно. ТЗ это не «ПЫТАЛИСЬ УАГАДАТЬ»!!! это «ЧТО НУЖНО». Хочу Х, проверяется Y. Фактически не имея ТЗ вы не можете ни бюджет, ни ресурсы распланировать для проекта! Фактически без ТЗ у вас НЕТ КОНТРАКТА!

                                                                                                                        Очень трудно вписать в ТЗ накладные расходы, связанные с отладкой стенда заказчки; штрафы за простой, пока заказчик правит свою сторону, в случае «хороших отношений» вписать просто невозможно.

                                                                                                                        Потому что бюджет к ТЗ не имеет отношение. это отдельный документ. и делается на основе ТЗ и после ТЗ.
                                                                                                                        А вопрос «включить» — это управление рисками. На это все есть своя «магия», ее нужно просто делать.
                                                                                                                          +1
                                                                                                                          По первому примеру не вижу большой проблемы: довольно скоро с таким исполнителем просто никто не станет работать.
                                                                                                                          — Здрасьте, мы такие-то, может, посотрудничаем?
                                                                                                                          — А, те самые, у которых «всё субъективно» и «на рекомендации мы клали с прибором»? Наслышаны, прощайте.
                                                                                                                            0
                                                                                                                            Или другой вариант: эти ребята знают, что происходит в коде, а другие нет. В итоге получается такой милый vendor lock-in.
                                                                                                                            Плюс не забывайте — если подрядчик сэкономил на разработчиках/тестировщиках, то он может давить ценой.

                                                                                                                            Как пример из жизни — Tata Consultancy Services.
                                                                                                                          0
                                                                                                                          Четкое детальное ТЗ просто жизненно необходимо для взрослых проектов, когда:
                                                                                                                          • Договор предусматривает ответственность за срыв сроков или несоответствие ожиданий клиента конечному результату.
                                                                                                                          • Заказчик скандальный, капризный или имеет за спиной судебные тяжбы с иными исполнителями. Либо клиент новый и информации о нем недостаточно.
                                                                                                                          • Заказчик действительно может более-менее точно сформулировать свои пожелания.
                                                                                                                          • Разработка ведется группой разработчиков, каждый из которых может взять на себя конкретный пункт ТЗ. Очень удобно, что разработчик четко понимает зону своей ответственности и объем работ без лишних объяснений.


                                                                                                                          Но бывают также случаи, когда излишне громоздкое ТЗ больше вредит, чем помогает:
                                                                                                                          • на его составление и проработку тратится время, зачастую немалое. При этом клиент не хочет вникать в технические нюансы и вообще, проект ему нужен исключительно как затычка: «Чувак, просто возьми мои деньги и дай мне товар! Ты лучше меня знаешь, как это должно работать».
                                                                                                                          • ограничивается творческая свобода разработчика, превращая работу в набор рутинных операций. Вместо того, чтобы создать простой стандартный интерфейс за 10-15 минут, разработчик 2-3 часа читает ТЗ и реализует «фичи», которые на самом деле никому не нужны.
                                                                                                                          • упираясь рогом в ТЗ, вы не даете клиенту то, что он желает получить в результате.


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

                                                                                                                            Компания или фрилансер предоставляет услуги. ТЗ — это лишь часть общего бизнес-процесса. Какая разница как бизнес работает с ТЗ, если в итоге это ведет к удовлетворительным для бизнеса результатам? Т.е. идти ведь надо от целей бизнеса, а не от хотелок бизнес-аналитика.

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

                                                                                                                            Вариант «Без ТЗ мы страдаем, но все равно делаем все без ТЗ» — если вы все еще на рынке, то значит не так уж и страдаете :)
                                                                                                                              –2
                                                                                                                              Спасибо за фитбэк

                                                                                                                              Я если честно шокирован, что у проблемы есть столько точек зрения, которые я сегодня узнал -)
                                                                                                                              +1
                                                                                                                              Только что закончили основной этап проекта по созданию куба БЕЗ ТЗ. Некий вариант «заказчик не знает как должно быть», но с добавлением, что и исполнитель не знает, как это можно сделать. :)
                                                                                                                              Успешно.
                                                                                                                              Это был АДЪ :)

                                                                                                                              НО.

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

                                                                                                                              Общая задача:
                                                                                                                              Надо разложить себестоимость продаж (фактически — отдельные фин проводки) на составные элементы с точностью до инвойса от поставщика товаров / услуг. Также нужны аналогичные отчеты по себестоимости, которая отнесена на конкретные партии закупленного материала на всем пути от завода до покупателя.

                                                                                                                              Куб предназначен в первую очередь для финансистов. Данные надо получать из ERP — MS Dynamics NAV. При этом данные надо ОЧЕНЬ сильно трансформировать перед загрузкой в куб.

                                                                                                                              То есть человек, который мог бы написать ТЗ, должен:
                                                                                                                              — иметь знания в области финансов (финансисты понимали, что им надо, но объяснить чистым ИТишникам не получалось)
                                                                                                                              — иметь знания, как работает MS Dynamics NAV (один из самых сложных модулей — расчет себестоимости)
                                                                                                                              — разбираться, как можно преобразовать данные в нужный формат
                                                                                                                              — разбираться в кубах (SSAS)
                                                                                                                              Найти человека, который знает что-то одно — легко. Всё вместе — нет таких (не смогли найти).
                                                                                                                              А так, что один умеет читать, а другой — писать — не получается. Слишком много всего надо учесть и все вещи слишком взаимосвязаны…
                                                                                                                              Например, нельзя проектировать куб, не понимая, какие данные и в каком формате можно получить из системы. А не разбираясь в финансах, нельзя решить — подойдет некая структура куба для получения нужных отчетов или нет.

                                                                                                                              Было весело… :)))
                                                                                                                                0

                                                                                                                                Работать без ТЗ — тяжело, но иногда трудозатраты по ТЗ сравнимы с затратами на финальный код и в таких случаях код = ТЗ.

                                                                                                                                  +1
                                                                                                                                  Например для небольшого отчета мне проще после общего описания хотелок сразу написать тестовый вариант. После этого все смотрят на отчет с живыми данными (это часто важно) и озвучивают дополнительные пожелания. Часть пожеланий сразу отклоняется, остальные реализовываются.
                                                                                                                                  Написание ТЗ в таких случаях — лишняя работа. Ведь для грамотного ТЗ всё равно надо проанализировать структуру данных — что и в каком виде можно получить. То есть фактически для написания ТЗ надо создать отчет :)
                                                                                                                                    0
                                                                                                                                    Дополню — написание именно «формального» ТЗ в таких ситуациях является лишним.
                                                                                                                                    ТЗ пишется, только в неявном виде.
                                                                                                                                    Для отчета в качестве ТЗ выступает сам отчет (тестовая версия) + пожелания по добавлению / изменению полей.
                                                                                                                                    Или это может быть тестовая версия кода, который реализует некую относительно простую функциональность + пожелания пользователей. Но с кодом сложнее — если может затронуть другие модули, то очень желательно написать формальное ТЗ.
                                                                                                                                  0
                                                                                                                                  Прекрасное продолжение прекрасной темы, спасибо. Из опыта моей компании могу сказать что нам удавалось построить работу без ТЗ таким образом, что все в итоге остались довольны. Сразу скажу, что клиент, взятый в качестве примера — это не мелекий стартап, а огромная немецкая(!) компания, старающаяся внедрять у себя принципы Agile-thinking, которые в понимании компании-заказчика делают ТЗ не только ненужным, но и вредным. Проект был суровым энтерпрайсом — Data Warehousing, ETL, MDM и Metadata. Т.е. области, в которых наличие не просто ТЗ, но детального системного анализа считается необходимым.

                                                                                                                                  Решение было очень простым — чистый time&materials, почасовая ставка (близкая к потолочной, но без всякого умножения на три). Разумеется, люди которые работали на клиента были весьма опытными разработчиками, полностью готовыми к ситуации и относились к изменениям генеральной линии как к «любой каприз за ваши деньги».

                                                                                                                                  Все закончилось хорошо :) Справедливости ради надо сказать что проект здорово облегчала рабочая атмосфера и философия клиента ( все крайне спокойно, никакого прессинга ), а так же тот факт, что суть проекта предполагала работу в основном на уровне архитектуры системы, без глубокого погружения в бизнес-логику.
                                                                                                                                    0
                                                                                                                                    В ходе обсуждения у меня уже не раз складывалось чувство, что Agile и ТЗ взаимоисключают друг-друга. Никак не могу понять почему?

                                                                                                                                    Какие аргументы использовал клиент, когда обосновывал вредность ТЗ для Agile?
                                                                                                                                      0
                                                                                                                                      Предположу, что дурацкие «работаем без документации» проистекают из этих трех строчек:
                                                                                                                                      • Люди и взаимодействие важнее процессов и инструментов
                                                                                                                                      • Работающий продукт важнее исчерпывающей документации
                                                                                                                                      • Сотрудничество с заказчиком важнее согласования условий контракта


                                                                                                                                      и попыткам следовать им буквально. На мелких проектах это прокатывает…
                                                                                                                                      Называется научи дурака молиться, он и лоб расшибет.
                                                                                                                                      Пытался выяснить, обсудить. Все упиралось в «написано!» Прямо как религиозная секта :)
                                                                                                                                        0
                                                                                                                                        Agile и ТЗ — богатая тема :) Можно смело писать отдельную статью-холивар :) Лично я не считаю что Agile ИСКЛЮЧАЕТ ТЗ. Не думаю что и заказчик занимал какую-то суровую позицию по поводу ТЗ в Аджайле. Просто в проекте который достался нам, ТЗ не было. И представители заказчика считали что оно и не нужно. Аджайл же. Естественно, в начале мы завели разговор о ТЗ, но проанализировав структуру команд и уровень компетенции в команде заказчиков, поняли что ТЗ ждать просто не от кого.

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

                                                                                                                                        Так что хоть со стороны заказчика ТЗ и не было, но проектная документация с нашей стороны, которую предъявляли заказчику и согласовывали с ним, все же была :)
                                                                                                                                          0
                                                                                                                                          Agile исключает классическое ТЗ. Суть agile в этом разрезе — быстрая реакция на изменяющиеся требования заказчика. Agile — средство от ситуаций, когда пишется ТЗ, согласовывается, ведётся разработка, сдаётся, заказчик принимает, поскольку работа соответствует ТЗ, оплачивает и выкидывает, решая купить коробку или нанять своих разработчиков, которые просто будут делать то, что заказчику нужно здесь и сейчас, а не говорить «сначала мы закончим работу по ТЗ, вы её оплатите, а потом будем писать ТЗ на доработки, переделки и удаление функциональности».
                                                                                                                                            0
                                                                                                                                            Классическое — пожалуй да. ТЗ вообще — описаный вами подход может работать на несложных проектах, вроде сайта-портала. Так же для небольших бизнесов, где падение системы не приведет к остановке работы в сотнях офисов по всему миру.

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

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

                                                                                                                                            Некий документ ( не важно как его называть) в этой ситуации необходимо хотя бы для того, чтобы в случае проблем, заказчику было сложнее заявить что это мы косорукие и все испортили — у нас остаются записи, что мы делали строго то, что хотел заказчик, и именно так, как он хотел.
                                                                                                                                        0
                                                                                                                                        Позволю себе предположить, что то, о чем вы говорите это «сервисный подход». В данном случае вы просто предоставли ресурсы под уже готовый проект. Все этапы планирования, аналитики — были на стороне Клиента. У вас же не спрашивали: Warehousing или нет. ETL или нет.
                                                                                                                                        Вам просто сказали: будет Warehousing. Есть ресурсы? Сколько стоит? То, что вам позволили сначала сделать кубик А вместо кубика B — это не ваша заслуга, не ваши риски. Не взлетел кубик? ну и фиг с ним, все равно уплачено.
                                                                                                                                        Если мое предположение корректно, то у вас был иной сценарий. А тут больше идет обсуждение в контекстве разработки и поставки Решения (Продукт под заказчика), причем он может его еще и не оплатить :)
                                                                                                                                          0
                                                                                                                                          Да, подход, конечно, сервисный. Мы предоставляли свои знания, опыт и компетенцию в виде сервиса. И конечно, нам сказали «хотим Warehousing».

                                                                                                                                          Насчет дальнейшего — все было не совсем так :) Не было со стороны заказчика ни планирования, ни аналитиков. Выше уже описал, скопирую сюда тоже:
                                                                                                                                          Просто в проекте который достался нам, ТЗ не было. И представители заказчика считали что оно и не нужно. Аджайл же. Естественно, в начале мы завели разговор о ТЗ, но проанализировав структуру команд и уровень компетенции в команде заказчиков, поняли что ТЗ ждать просто не от кого.

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

                                                                                                                                          Так что хоть со стороны заказчика ТЗ и не было, но проектная документация с нашей стороны, которую предъявляли заказчику и согласовывали с ним, все же была :)
                                                                                                                                            0
                                                                                                                                            Кроме сервиса разработки, вы добавили сервисы. Вы все равно как-то «на бумажке» зафиксировали ожидания Клиента, под них сделали Решение.
                                                                                                                                            Вот теперь все сошлось :) Видать пропустил что-то из описанного.
                                                                                                                                            Спасибо :)
                                                                                                                                        +1
                                                                                                                                        ИХМО жёсткое ТЗ обычно неэффективно. Часто на входе только цели проекта, критерии его успешности, сроки, примерный бюджет, ключевые требования. Не статичный список требований и их постепенная детализация через итерации — это нормально и было придумано задолго до agile.
                                                                                                                                        Если фикспрайс + фиксированные сроки + сложный заказчик, то ТЗ единственное, что может хоть как-то застраховать исполнителя. Другой вопрос, на каком этапе оно появляется.
                                                                                                                                          0
                                                                                                                                          еще бы увидеть ТЗ, в котором учтены все хотелки клиента и исключены неоднозначности. Любопытно было бы на него взглянуть и на потраченное кол-во часов на его составление. Бьюсь об заклад, что я найду даже в нем пару пунктов, которые я думал будут реализованы по другому.
                                                                                                                                            –1
                                                                                                                                            Отличная статья! Автор, ты умница!
                                                                                                                                              0
                                                                                                                                              Работаю в геймдеве, с ТЗ не сложилось.

                                                                                                                                              Обычно диалог с заказчиком такой:
                                                                                                                                              З: Нам нужна камера.
                                                                                                                                              Я: Ок, есть с десяток вариантов логики поведения камеры. Рассказываешь ему все варианты, попутно делаешь статью на хабр в двух частях.
                                                                                                                                              З: Ок, нам нужно посмотреть все варианты, высылайте демку.

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

                                                                                                                                              Но план работ всегда составляю и по нему потом уже оцениваю работу вместе с заказчиком, но назвать это полноценным ТЗ лично я не могу. Ну и мелкие итерации с оплатой за каждую, спасают.
                                                                                                                                                0
                                                                                                                                                А за чей счет банкет? вы сделали «свою камеру», а потом вас попросили переделать.
                                                                                                                                                Откуда бюджет на черновик и переделку? если Т&M — то риски на клиенте/инвесторе.
                                                                                                                                                0
                                                                                                                                                Начинали писать один сайт, пришел дизайнер UIX-иксперт, внес поправки и свое вИдение, и стали писать другой сайт. И так пару раз меняли тематику. Заказчик заезжал на чОрном джипе, и привозил зарплату. Все были довольны.

                                                                                                                                                Какое-такое ТЗ?
                                                                                                                                                  +1
                                                                                                                                                  Я читал статью, лицо мое вытягивалось, вытягивалось, рот открывался все шире и шире, но потом я прочел @krivotester Бизнес-аналитик и все встало на свои места.
                                                                                                                                                  Классная теория, бро, жаль только что с реальным миром никаким образом не соотносится.
                                                                                                                                                    0
                                                                                                                                                    Эммм ну я как-то функционирую:
                                                                                                                                                    Тз пишутся, проекты релизятся.
                                                                                                                                                    Вы считаете, что это только в моем воображении?
                                                                                                                                                      –1
                                                                                                                                                      Я как раз тот самый заказчик без ТЗ. Банкет я устраиваю за свой счет. Свои деньги вынимаю из оборота.

                                                                                                                                                      И вот, пожалуйста, реальный пример: мне нужно оптимизировать сбор статистики. Я оставляю 20 заявок и начинается. 10 компаний откликаются через сутки и более. Значит либо работать не умеют, либо клиенты не нужны — в мусорную корзину. 5 откликнувшихся компаний предлагают мне заполнить ТЗ (читать как — работать с нашей компанией большая честь, вам для работы следует: 1… 2… 3...) — опять в корзину.

                                                                                                                                                      Выбирать я буду их оставшихся 5 компаний, которые вместо того чтобы тратить мое время на распросы сразу направляют мне КП, и начинают меня пинать каждый день «когда рассмотрите». Вот этим парням (я так понимаю) работа нужна. Выбирать я буду их них, и естественно выберу самое дешевое предложение и буду стараться оплатить как можно меньше и получить как можно больше функционала и доп. поддержки.

                                                                                                                                                      Особенно я буду стараться избегать компаний с менеджерскими прокладами между мною (Заказчиком) и непосредственным разрабочиком (Исполнителем). Почему? Потому что программисты, как правило значительно просто отжимаются на бесплатую дополнительную работу.

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

                                                                                                                                                      Почему я так делаю? Потому что банкет — за мой счет, ничего личного.

                                                                                                                                                      ps. в вашем проффесионализме не сомневаюсь
                                                                                                                                                        0
                                                                                                                                                        Очень вас понимаю, у меня много клиентов с такой идеологией.

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

                                                                                                                                                        Банкет, как вы правильно заметили, за ваш счет и если кто-то хочет платить за дополнительные риски, то обращается в страховую компанию, а не к разработчикам -)
                                                                                                                                                          0
                                                                                                                                                          Зависит от объема/характера ваших задач.
                                                                                                                                                          Возможно, на ваших конкретных задачах, можно и без ТЗ вполне.
                                                                                                                                                          Например, на мелких задачах.

                                                                                                                                                          Но, как правило, если для вас важно в том числе и сэкономить деньги — именно ТЗ как раз и позволяет вам это сделать.
                                                                                                                                                            0
                                                                                                                                                            Для меня важно платить за результат, а не за фитнес.
                                                                                                                                                            Все остальное с дисконтом в 99,5%.
                                                                                                                                                              0
                                                                                                                                                              Ну то есть для вас важно минимизировать риски неполучения результата.

                                                                                                                                                              Нужно отдавать себе отчет, что при этом в денежном эквиваленте вы сильно переплачиваете. Так как исполнитель в этом случае тоже закладывает свои риски в стоимость работ, подробнее об этом написано тут: https://habrahabr.ru/post/315624/#comment_9952610

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

                                                                                                                                                              P.S.:
                                                                                                                                                              У меня вопрос (риторический) — где вы таких исполнителей берете, что так шугаетесь невыполнения взятых ими обязательств.
                                                                                                                                                                0
                                                                                                                                                                Ну то есть для вас важно минимизировать риски неполучения результата.

                                                                                                                                                                При чем тут риск менеджмент? Кстати в российском страховании я потерял 7 лет жизни и более-менее понимаю как все работает в этом грязненьком бизнесе. Риск-менеджмент и российское страхование (даже в западных франшизах) это просто разные категории.

                                                                                                                                                                Мне важно платить за результат. Я могу и не получить результата — это жизнь. Просто не хочу платить за «ну мы же много работали, кто же знал что <причина, которая мне не интересна>».
                                                                                                                                                                  0
                                                                                                                                                                  Это и есть риски. Не страховые, а обычные такие рядовые предпринимательские риски.
                                                                                                                                                                  Общепринятый термин.

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

                                                                                                                                                                    0
                                                                                                                                                                    Объясните, пожалуйста, какие риски я несу оплачивая результат только при увеличении моей товарной маржи? Если маржа не увеличится — я не плачу. Увеличится — плачу. Где риск?
                                                                                                                                                                      0
                                                                                                                                                                      Ваша маржа, нафиг никому не сдалась :) Это друга форма отношений.
                                                                                                                                                                      Вы покупатете сервис, что вы будете с ним делать — это только ваша проблема.
                                                                                                                                                                      Купили и хвастаетесь своему коту, или продаете через него аламазы — это только ваша проблема и заслуга.
                                                                                                                                                                      Если вы получили услугу с отсрочкой платежа, вам фактически сделали «товарный кредит». Кредит стоит денег :) Хотя бы курсовые риски и инфляцию, которые будут заложены, на ваш платеж, который пойдет на оплату облака Гугл/Амазон/ и т.д. :) А еще добавят вам зарплату того парня, что будет спрашивать у вас когда заплатите.
                                                                                                                                                                      А поскольку вы не показали серьезность намерений, то вам могут сделать «вот прямо сейчас» не заложив никаких точек расширения или роста и дальнейшие доработки вам будут стоить не 5 часов, а 10.

                                                                                                                                                                      Если вы сделали по предоплате: вам могут сделать скидку просто потому, что вы показали серьезность ваших намерений к работе.
                                                                                                                                                                      Вам могут просто предложить решение, которое будет, например, в облаке процентов на 10% меньше жрать ресурсов. доработка будет делать не 10 часов, а 5, потому что человек вам бесплатно заложил «точки расширения».
                                                                                                                                                                      Сделал на последней версии движка БД, а не на том, который через год просто не будет поддерживаться и т.д.
                                                                                                                                                                        0
                                                                                                                                                                        Вам могут просто предложить решение, которое будет, например, в облаке процентов на 10% меньше жрать ресурсов. доработка будет делать не 10 часов, а 5, потому что человек вам бесплатно заложил «точки расширения».
                                                                                                                                                                        Сделал на последней версии движка БД, а не на том, который через год просто не будет поддерживаться и т.д.


                                                                                                                                                                        Это маловероятно.
                                                                                                                                                                        Ведь наш заказчик выбирает самое дешевое решение,
                                                                                                                                                                        а вещи с экономией потом в будущем — стоят денег уже сейчас.
                                                                                                                                                                          0
                                                                                                                                                                          Когда узнает что такое ROI и TCO, посмотрит свои финансовые модели за годик другой — вероятность изменяется обычно :)))))
                                                                                                                                                                            0
                                                                                                                                                                            Если у тебя тупо нет бабла — можно сколько угодно читать про крутые технологии.
                                                                                                                                                                            Но бабла нет — не закажешь ничего серьезного.
                                                                                                                                                                              0
                                                                                                                                                                              купи готовый сервис и не дури голову ни себе не людям :)
                                                                                                                                                                              Думаю грамотнтый так и скажет «вот Коробочка, вот ее цена». пользуйтесь :)
                                                                                                                                                                        0
                                                                                                                                                                        Объясните, пожалуйста, какие риски я несу оплачивая результат только при увеличении моей товарной маржи? Если маржа не увеличится — я не плачу. Увеличится — плачу. Где риск?


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

                                                                                                                                                                        Но риски возросли у разработчиков,
                                                                                                                                                                        поэтому они запросили с вас больше бабла.
                                                                                                                                                              0
                                                                                                                                                              Как-то очень жалко стало вашего исполнителя. Глядя на такие истории, и впрямь задумаешься, что со стороны исполнителя ТЗ не помешает. А ещё лучше просто не связываться с хитрожопыми заказчиками, а если не получилось избежать неприятностей — выходить как можно раньше.
                                                                                                                                                                +1
                                                                                                                                                                > программисты, как правило значительно просто отжимаются на бесплатую дополнительную работу
                                                                                                                                                                > который делает мне результат, за недорого и еще за бесплатно допиливает его 4 месяца

                                                                                                                                                                Это сработает только с достаточно простыми задачами: таких, простите за выражение, лохов можно найти только среди начинающих разработчиков. Конечно, с малой вероятностью можно наткнуться на хорошего программиста, но наивного растяпу по жизни, который решил попробовать фриланс (и этот опыт будет его первым и на многие годы последним).

                                                                                                                                                                Со сложными задачами скорее получится так, что вы 10 раз смените подрядчиков, но так и не получите нужного результата. В лучшем случае получится что-то еле-еле работающее из-за того, что каждаая доделка сделана грубым костылем, и в итоге уже весь проект из них и состоит, а скорее всего не получите вообще ничего работоспособного. Для таких задач опытный фрилансер с хорошей почасовой оплатой, умеющий вести переговоры и вынимать из вас ваши будущие хотелки еще до того, как вы сами их осознали, в итоге обойдется дешевле, и при этом все будет ко взаимному удовольствию.
                                                                                                                                                                  0
                                                                                                                                                                  Это сработает только с достаточно простыми задачами: таких, простите за выражение, лохов можно найти только среди начинающих разработчиков. Конечно, с малой вероятностью можно наткнуться на хорошего программиста, но наивного растяпу по жизни, который решил попробовать фриланс (и этот опыт будет его первым и на многие годы последним).


                                                                                                                                                                  Даже самые простые вещи тоже могут приносить огромные деньги прибыли.
                                                                                                                                                              0
                                                                                                                                                              Не могли бы Вы как-то отметить пункты, которые по Вашему мнению не соотносятся с реальным миром? может быть добавите свои сценарии из реального мира?
                                                                                                                                                              это не подколка, а просьба поделиться опытом :)
                                                                                                                                                                0
                                                                                                                                                                Пожалуйста:

                                                                                                                                                                1.
                                                                                                                                                                Потеря клиента лишь стимулирует активнее искать новых.

                                                                                                                                                                Это правда. Где-то до 5го (10го, 20го, нужное подставить) клиента, после чего встанет выбор — размещать резюме и начинать экстренно искать работу, снова занимать денег (хорошо если есть где) или переходить на питание духовной пищей (а если есть семья, то и их тоже на духовные харчи переводить). В этот момент как правило происходит прозрение.

                                                                                                                                                                2.
                                                                                                                                                                На самом деле, крупные компании не боятся крупных сумм, особенно если ты их можешь обосновать.

                                                                                                                                                                Что такое обосновать крупную трату: «мы подписываемся за результат X, за Y денег, если результата не будет то и платить нам не надо». Кстати вполне соотносится с 60-ти дневной задержкой по оплате оказанных услуг. Нет результата — за что платить?

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

                                                                                                                                                                4.
                                                                                                                                                                Разработчик на зарплате любезно сообщает ей, что она должна

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

                                                                                                                                                                5. Богатый школьник говорит
                                                                                                                                                                Я не знаю, чего хочу — предложите варианты!

                                                                                                                                                                Ну еп. Как на такое вообще можно жаловаться? Мне бы таких и побольше :)
                                                                                                                                                                  0
                                                                                                                                                                  неквалифицированные заказчики

                                                                                                                                                                  К сожалению, это проблема. Отсутсвие квалификации проявляется следующим образом:
                                                                                                                                                                  Если вы внедряете такое решение извещаете Клиента:
                                                                                                                                                                  Вам нужно сделать следующее, что бы не было проблем (к примеру):
                                                                                                                                                                  • Разработать политику резервирования и восстановления
                                                                                                                                                                  • Этапы внедрения решения настоятельно! рекомендуем следующие… потому-что…
                                                                                                                                                                  • У вас должны быть готовы справочные данные по следующим правилами потому-что


                                                                                                                                                                  Квалифицированный клиент:
                                                                                                                                                                  • Ок парни. вот мы тут сваяли политику. гляньте? может чего рекомендуете
                                                                                                                                                                  • Ок парни. вот мы тут сваяли график внедрение. гляньте? может чего рекомендуете
                                                                                                                                                                  • Ок парни. вот мы тут справочные данные. гляньте? может чего обсудим


                                                                                                                                                                  НЕ Квалифицированный клиент:
                                                                                                                                                                  • Фигня. у нас все есть.!
                                                                                                                                                                  • Не ваша проблема! не первый раз.
                                                                                                                                                                  • Да у нас 1С/ CRM / ERP. Выгрузим-загрузим. 5 минут делов. Не баитесь!


                                                                                                                                                                  не говоря о том, что бы получить встречу с кем-то из других участников проекта клиента, огранизовать тестирование у себя и т.д.
                                                                                                                                                                  Угадайте, в каком случае наступит #@&% когда придет время раскатывать на сервер?
                                                                                                                                                                  И кому будут выносить мозг и как, когда у клиента сложится рабочая система?
                                                                                                                                                                    0
                                                                                                                                                                    К сожалению, это проблема.


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

                                                                                                                                                                    Если бы заказчик сам разбирался — он бы не платил вам как квалифицированному специалисту, а платил бы как… гм… уборщице, например.

                                                                                                                                                                    Если вас напрягают такие заказчики — идите на крупную фирму и работайте через менеджеров-постановщиков задач, а не напрямую с клиентом.

                                                                                                                                                                    Квалифицированный клиент:

                                                                                                                                                                    • Ок парни. вот мы тут сваяли политику. гляньте? может чего рекомендуете
                                                                                                                                                                    • Ок парни. вот мы тут сваяли график внедрение. гляньте? может чего рекомендуете
                                                                                                                                                                    • Ок парни. вот мы тут справочные данные. гляньте? может чего обсудим


                                                                                                                                                                    А за что платить вам?
                                                                                                                                                                    За погляд?

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

                                                                                                                                                                      Не квалифицированный тупо забьет, на то что ему говорят пофиг платно или бесплатно. А когда получит граблями в лоб, еще и обижаться будет что ему бесплатно не исправляют и не заставили! прочитать руководтво по эксплуатации перед тем как 200 человек посадить на новую систему.
                                                                                                                                                                        0
                                                                                                                                                                        Еще раз:

                                                                                                                                                                        Если вы работаете с заказчиками напрямую — то выяснять ТЗ и объяснять как внедрять — это часть вашей работы.

                                                                                                                                                                        Квалификация заказчика тут ровным счетом не причем.
                                                                                                                                                                        Он вас потому и нанял, что в этой сфере вы более квалифицированы, чем он.

                                                                                                                                                                        Ваше дело — просто включить надбавку в счет за эту свою доп. работу.
                                                                                                                                                                          0
                                                                                                                                                                          Именно что причем.
                                                                                                                                                                          Есть куча проблем, которые следует согласовать с заказчиком, до того как…
                                                                                                                                                                          Например:
                                                                                                                                                                          • политики безопастности. Например, он бится что украдут базы клиентов.
                                                                                                                                                                          • юридические политки. требует, что бы все разработчики были в штате.
                                                                                                                                                                          • бизнес-политики. никакого итеративного подхода, только хардкор! только за одну ночь и в одном контракте!

                                                                                                                                                                          А если у клиента уже есть какие-то ИТ решения? Тогда ты должен под них «подстроиться», что бы было Клиенту удобно.
                                                                                                                                                                          Например: у клиента инфраструктура Оракл, а ты ему предлагаешь решения на стеке Микрософт, потому что он тебе просто не сказал про Оракл.
                                                                                                                                                                          Один аж пищат хочет облака, другие он них шарахаются.
                                                                                                                                                                          Третьи хотят только OpenSource решения,
                                                                                                                                                                          У Клиента есть свои представления, как он хочет развернуть инфраструктуру.
                                                                                                                                                                          У него уже закуплено и развернуто оборудование со специфическими конфигами, а тебя просто не допускают до него.

                                                                                                                                                                          Я у него «гость» и я не могу ломиться в «закрытые» двери.
                                                                                                                                                                          Например:
                                                                                                                                                                          В одном проекте предупредили клиента письменно:
                                                                                                                                                                          Перед развертыванием решения или внесением изменений, мы вас извещаем. Вы делаете резервную копию (нам прав не дали), и после вашего подтверждения мы разворачиваем.
                                                                                                                                                                          Клиент подтверждает: ОК.
                                                                                                                                                                          Развернули решение. Через два месяца звонит и требует «ремонта по гарантии». Полезли разбираться. Оказалось, что Клиент поменял менее 24 часов назад конфигурацию решения, потеряв часть своих данных. Позвонили клиенту через минут 30 и известили. Сказали что бы срочно откатил из резевной копии потому что…
                                                                                                                                                                          Клиент сказал: ОК. буду делать.
                                                                                                                                                                          Через два дня звонок от пользователя — что за хрень ?! почему все сломано ?!
                                                                                                                                                                          Проверили: клиент нифига не откатил.
                                                                                                                                                                          Начали разбираться, оказалось что клиент просто не делал резервные копии… @#@$
                                                                                                                                                                          Вот нафига был врать «парни все ок, у нас все есть»?
                                                                                                                                                                            0
                                                                                                                                                                            Я у него «гость» и я не могу ломиться в «закрытые» двери


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

                                                                                                                                                                            Но выцепить все детали.

                                                                                                                                                                            Если вы этого не делаете, то или завышаете цену, закладывая в нее риски.

                                                                                                                                                                            Или берете на себя все риски — но это ваше личное решение.
                                                                                                                                                                            И никто (кроме вас) не виноват, что заказчик оказался не компетентным и вы этого не учли и не скомпенсировали узнаванием деталей/повышением цены.

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

                                                                                                                                                                              Были интересные задачи:
                                                                                                                                                                              • система оценки кредитных рисков для банков. Ее приемка идет по тестовым сценария. подготовленным банком. и если банк накосячит — на выходе будет фигня. Это секретная информаци и я не могу никак ее выцепить.
                                                                                                                                                                              • Работа с госсистемами, которые имеют «гриф». Суровые люди тебе просто говорят — должно быть вот так. Хотя с точки зрения здравого смысла/ опыта это бред сумашедшего.
                                                                                                                                                                              • Нафига мне знать обороты Большой Компании и через кого идет работа с офшорами? движуха по счетам ?

                                                                                                                                                                              Я вынужден доверять тому, что мне сказано Клиентом, если он отказывает мне в проверке предоставленных им данных. А что бы «не попасть» вынужден защищаться юридически.
                                                                                                                                                                              Вы в больнице подписываете форму, на что у вас есть аллергия. Если вы солгали и вам ввели опасное вам вещество, вы можете умереть. Подписанная форма снимает ответственность с врача. Люди это понимают и говорят правду. А в ИТ — нифига. Зачем ?!
                                                                                                                                                                              Вам пломбу поставили и предупредили не есть орешки? Вы начали щелкать грецкие орешки и отрывать пиво и зуб под удаление? Вы сам себе злой буратино. А в ИТ? А зачем ?!

                                                                                                                                                                              Мы спецы, у нас дохрена опросников и чеклистов, как не накосячить, но я не могу заставить клиента их прочитать, потому что «5 откликнувшихся компаний предлагают мне заполнить ТЗ (читать как — работать с нашей компанией большая честь, вам для работы следует: 1… 2… 3...) — опять в корзину.»
                                                                                                                                                                              Я могу только в контрате написать «что не оговорено в ТЗ и критериях приемки, делается за отдельную плату».
                                                                                                                                                                              И если мне Клиент солгал или не знал или не захотел сказать когда я его спрашивал, что вместо 10 человек запланированных, у него будет работать 100 — я с чистой совестью, выкачу ему счет за решение возникшей проблемы:)
                                                                                                                                                                    0
                                                                                                                                                                    Это правда. Где-то до 5го (10го, 20го, нужное подставить) клиента, после чего встанет выбор — размещать резюме и начинать экстренно искать работу, снова занимать денег (хорошо если есть где) или переходить на питание духовной пищей (а если есть семья, то и их тоже на духовные харчи переводить). В этот момент как правило происходит прозрение


                                                                                                                                                                    Сейчас дефицит квалифицированных ИТ кадров.

                                                                                                                                                                    При этом кто-нибудь на ваш призыв, разумеется, откликнется.

                                                                                                                                                                    А сделать что нибудь более-менее не тривиальное, в сроки и без косяков — таких спецов нужно искать и задачи у них расписаны на недели (в лучшем случае на недели; у меня, к примеру — на пару месяцев) вперед.
                                                                                                                                                                      0
                                                                                                                                                                      Эмм ну может быть да, мы из параллельных реальностей:

                                                                                                                                                                      1. Семья и двое детей имеется. Хвататься за каждого клиента, который будет из меня что-то отжимать как и когда ему хочется не прибыльно, пусть лучше идет к конкурентам и жрет их ресурсы -). Свой бизнес у меня с 2009-ого, полет нормальный.

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

                                                                                                                                                                      3. Часто мои заказчики — разработчики программного обеспечения. Иногда выступаю мостом между разными командами разработчиков. Квалифицированные заказчики есть на рынке, а разделение труда — это нормально.
                                                                                                                                                                      На фриланс биржу не лезут не потому что не квалифицированы, а потому что бизнес в другом.

                                                                                                                                                                      4. Толкового разработчика найти сложно. Новый разработчик на зарплате не появляется ни завтра ни через месяц, даже на довольно простых проектах. Недавно клиенты два месяца HTML-верстальщика банального в офис искали два месяца.

                                                                                                                                                                      5. Охмурять школьников, и в целом охмурять — не мой бизнес. Не хочу, чтобы таких было побольше.
                                                                                                                                                                        0
                                                                                                                                                                        Кстати вполне соотносится с 60-ти дневной задержкой по оплате оказанных услуг. Нет результата — за что платить?


                                                                                                                                                                        На самом деле конечный покупатель платит за все это.
                                                                                                                                                                        Всегда. Всегда платить покупатель. За все.

                                                                                                                                                                        Это будет или предоплата, куда фактически заложена эта 60-ти дневная оплата пропитания разработчика (та минимальная цена, за которую еще разработчик может работать). А вторая часть оплаты — это уже чистая премия разработчику за счет заказчика, то есть речь не идет ни о какой экономии и самых дешевых разработчиках — это всего лишь самообман. Самыми дешевыми получаются только те, кому платят ежедневно.

                                                                                                                                                                        Либо это будет просто завышенная оплата в конце — куда заложены все риски. А это очень большая переплата.

                                                                                                                                                                        P.S.:
                                                                                                                                                                        Работаю на фриленсе лет 13 уже.
                                                                                                                                                                        Все риски всегда на заказчике, даже если заказчик думает, что он самый умный и платит только по факту.
                                                                                                                                                                        Иначе я давным давно двинул бы кони.
                                                                                                                                                                        Скидку заказчик получает только по предоплате. При постоплате заказчик получает наценку. Всегда.
                                                                                                                                                                        Это жизненно необходимо для закрытия себя от рисков.
                                                                                                                                                                          0
                                                                                                                                                                          Были бы все заказчики квалифицированы — закупались бы на фриланс биржах напрямую, а не через прокладки.


                                                                                                                                                                          Отнюдь, и не суть в этом.

                                                                                                                                                                          Иногда (часто) заказчика не нужны риски.
                                                                                                                                                                          Заказчикам нужен комфорт.

                                                                                                                                                                          И чем крупнее проект — тем больше риски с фриленсерами.
                                                                                                                                                                          Если заказчик сам управляет этими рисками, то есть сам возится с фриленсерами, ежедневно их контролируя — то так жить можно.

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

                                                                                                                                                                          И чем заказчик крупнее (богаче, жирнее) — тем он больше имеет возможностей на кого-то переложить свои головняки и сосредоточиться на главном.

                                                                                                                                                                          Для мелкобизнесменов разумеется, крайне выгодным является самому стать квалифицированным — это позволяет существенно экономить.

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

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

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

                                                                                                                                                                                0
                                                                                                                                                                                Если надо все-таки ехать, а не препираться.

                                                                                                                                                                                То нужно брать минимальную задачу, просить чтоб разрабы составили ТЗ на первый мини-этап и платить за сделанный этап.

                                                                                                                                                                                Дешево, быстро, квалификация большая не нужна, все едет.

                                                                                                                                                                                Вот что мешает работать так?
                                                                                                                                                                                  0
                                                                                                                                                                                  Потому что можно прекрасно работать без ТЗ.
                                                                                                                                                                                  Удачно и годами.

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


                                                                                                                                                                                    Если ваш опыт обошелся Вам дороже, чем потом применение вашего опыта на практике — какой вам смысл вообще работать? Это ж сплошные убытки.

                                                                                                                                                                                    Прошлый опыт — намного дешевле, чем тот профит, что мы с него потом получаем.
                                                                                                                                                                        +1
                                                                                                                                                                        Ну во-первых, как тут многие сказали, обычно ТЗ, который приносит заказчик — это мусор, который в 90% выкидывается в помойку. Во-вторых, картина обычно следующая:
                                                                                                                                                                        Заказчик: Вот вам ТЗ, делайте.
                                                                                                                                                                        Исполнитель — Яволь!
                                                                                                                                                                        Через какое-то время…
                                                                                                                                                                        Исполнитель: сделали
                                                                                                                                                                        Заказчик: Что это?
                                                                                                                                                                        И: Ну как, по ТЗ.
                                                                                                                                                                        Далее возможны варианты — мы не то просили (конечно, одно дело бумажка, другое дело реальный продукт). Или — вы с ума сошли? Уже год прошел — бизнес поменялся, нам теперь это вообще не надо.
                                                                                                                                                                        Да, исполнитель получит деньги, заказчик будет недовольный, а продукт пойдет на полку…

                                                                                                                                                                        PS Уже лет 15 лет работаю в основном на внутренних проектах, работал и в аутсорсе немного, но на внутренних проектах ТЗ не нужно. Напрасная трата времени и денег. Есть конкретный заказчик, есть исполнитель — все довольны, все ОК. И софт, которым пользуются.
                                                                                                                                                                        • UFO just landed and posted this here
                                                                                                                                                                            0
                                                                                                                                                                            1. ТЗ это инструмент для налаживания взаимопонимания, идеально когда оно отвечает на вопрос:
                                                                                                                                                                            — что надо сделать?
                                                                                                                                                                            — на вопрос КАК надо сделать ТЗ отвечает не всегда, т.к. не всегда это понятно и есть много вариантов.
                                                                                                                                                                            2. ТЗ должно быть понятно и заказчику и исполнителю
                                                                                                                                                                            3. Читать должны заказчик и исполнитель.
                                                                                                                                                                            — хорошо когда ТЗ из маленьких блоков, которые легко превращаются в задачи в таск-менеджере
                                                                                                                                                                            — я люблю когда один блок — одна демонстрация, чем раньше начать демонстрацию готовых кусков по ТЗ заказчику — тем лучше, тем меньше переделок, тем меньше непонимания
                                                                                                                                                                            4. Вместе! Работа совместная, иначе ад
                                                                                                                                                                            5. Хорошо бы иметь опыт уже реализованных похожих проектов
                                                                                                                                                                            6. Критерий качества: заказчик и исполнитель готовы расписаться, что понимают что нужно сделать
                                                                                                                                                                            7. Я предпочитаю
                                                                                                                                                                            — писать ТЗ на маленькие этапы, в них изменения либо некритичные, либо приводят к отмене всего этапа и пересмотру всего контракта
                                                                                                                                                                            — я предпочитаю предложить доделать этап и к нему написать новое ТЗ на изменение
                                                                                                                                                                            * иначе все вязнет
                                                                                                                                                                            8. Аналитик — отвечает за выстраивание отношений с заказчиком и разработчиком. Он занимается челночной дипломатией, помогает достичь договоренностей. Чтобы с одной стороны заказчик получил именно то, о чем мечтал, с другой стороны чтобы это что-то было понятным и реализуемым.
                                                                                                                                                                            Аналитик помогает заказчику сформулировать задачи, а разработчикам сформулировать ограничения.
                                                                                                                                                                            9. ТЗ помогает помнить договоренности и по возможности не уходить от них далеко. Судебный процесс — дело на годы, если взаимонепонимание зашло так далеко, то в суде ТЗ не особо кого спасет.
                                                                                                                                                                            10. ТЗ — это план для будущего user manual, но не его содержание.

                                                                                                                                                                            Резюмируя:
                                                                                                                                                                            ТЗ отвечает на вопрос: «Что нужно сделать?»
                                                                                                                                                                            Проектная документация отвечает на вопрос: «Как это сделать?»
                                                                                                                                                                            Мануал отвечает на вопрос: «Как это эксплуатировать?»
                                                                                                                                                                            Аналитик помогает сформулировать задачи с одной стороны и ограничения по реализуемости с другой стороны