Работа с клиентом или «почему вы не сделали то, что мы просили?»

Предисловие


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

Эпизод I: «Начало»


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

«Hi, Michael. I want to introduce you our team...»

Менеджер, ловко оперируя словами, заставляет клиента почувствовать всю серьёзность нашей компании. Он никогда не узнает, кто сколько выпил в воскресенье на корпоративе и почему на нашей таск-борде (обычная белая доска с маркером) очень много мата. Далее, после всяких капиталистических фамильярностей, начинается процесс обсуждения проекта. В этот момент тимлид включает запись звука в компьютере и записывает весь процесс обсуждения проекта. В последствии бедной девочке-менеджеру придётся сделать полную стенограмму этого разговора. В процессе обсуждения проекта заказчик высирает выдаёт все известные ему идеи, которые он только хочет видеть реализованными. Мы отвечаем ему, что приступим к подготовительной части проекта, и, довольные, заканчиваем разговор. Далее менеджер уходит делать стенограмму, а девелоперы возвращаются к чтению статей. Это последние спокойные часы, затишье перед бурей…

Эпизод II: «Snowballing»


После того, как девушка-менеджер окончила стенограмму и вместе с тимлидом выделила основные аспекты будущего проекта, вся команда собирается у таск-борды и обсуждает каждый пункт из этого длинного списка. Этот процесс называется фичекатом(от англ. feature cut — «отрезание» деталей). Все фичи, которые запросил клиент, обсуждаются и относятся в три группы:
  • required/core features
  • optional/useful features
  • костыляble/useless features

В первую группу относят основные фичи, которые попросил заказчик. Это скелет проекта, основной функционал, который будет реализован на проекте. Во вторую группу входят фичи, которые не обязательны к выполнению для функционала сайта с нашей точки зрения и мы можем отказаться от них, если это будет технически сложно/невыгодно. Последняя группы — это те фичи, которые по нашему опыту абсолютно не нужны и даже могут создать сложности в будущем. Ко всему прочему, на основании анализа этих пунктов, можно добавить какие-то фичи во второй и третий пункт. Например жёсткая интеграция с какой-то определённой базой данных (Oracle DB) будет в третьем пункте. Зато в первом пункте появится такая фича, как «реализация работы с множеством других типов баз данных».

А где же ТЗ заказчика, спросите вы? Разве он его не присылал? Конечно присылал. В этот ТЗ заказчика мы вносим свои правки и предоставляем ему на подтверждение. Если он согласен — нам повезло. А если не согласен — будем уговаривать согласиться, пока он нас не задавит, и мы не прогнёмся. Ну, говнокодить так говнокодить, мы сделали всё, чтобы этого избежать.

Эпизод III: «Дивелапинг»


Проект набирает обороты! После окончательного утверждения ТЗ, его разбивают на таски (задачи) и выставляют эстимейты (сметы, оценки). Чем адекватнее требование, тем адекватнее эстимейт. Например, все фичи из третьего пункта будут неадекватно заэстимейчены. И это очень важно и правильно, об этом будет чуточку позже. Далее команда собирается, обсуждает общую архитектуру, распределяются таски и всё такое, короче говоря, работа кипит. Если в процессе заказчик вносит какие-то правки, их оценивают и тоже эстимейтят. О правках тоже чуть позже. Короче разрабы пашут аки кони, и всё у всех хорошо.

Эпизод IV: «Сдача проекта»


Тут может быть очень много проблем и вообще всего. Весь проект делается полностью по ТЗ и только по ТЗ. Больше документов, которые выставляют для вас цели, нет. Ни переписки, ни «я вам говорил по скайпу», ни «ну вот у них это сделано вот так, а вы вот не так, вообще». Ни-че-го. С другой стороны, всё должно быть строго по ТЗ. Именно для того, чтобы таких ситуаций не возникало, мы стенографируем общение с заказчиком и пересматриваем ТЗ, вносим правки. И всё равно, ядрён конь, эти ситуации возникают. Кто-то не то сделал, кто-то что-то не так понял и понеслось. Один раз мы получили письмо, в котором слово «f*ck» и производные составляли процентов 70-80 от всего текста. Дайте заказчику выругаться. Пусть выпустит пар. А дальше формируем новое ТЗ для «допиливания напильником»: стили подогнать, разукрасить как надо, SEO настроить и так далее. Выставляем эстимейт, скромненький, но обязательный, заказчик оплачивает и доводим всё до идеала. В конце концов 90% заказчиков довольны. Остальные 10% — заказчики из России или Украины.

Эпизод V: «Империя наносит ответный удар»


Разработал? Так иди и поддерживай. Во-первых, на поддержку опять же выставляется эстимейт. В среднем, саппорт-тим одного проекта состоит из одного разработчика, он тратит на это 30 часов в неделю. Он копается в сайте, поднимает базу, если та падает, делает мелкие фиксы. Если намечается хоть какой-нибудь мало-мальски большой баг — сразу в эстимейт. В это время заказчик придумывает всё новые и новые фичи. Кто их будет делать? Мы! На каждую фичу — эстимейт. Поменять фотографию на сайте — эстимейт. Добавить в базу таблицу — эстимейт. Он хочет в нас плюнуть — эстимейт. Да-да-да, эстимейт на каждый плевок. Пусть платит за это деньги. Потому что если хоть раз дать ему плюнуть в нас бесплатно — он нас заплюёт до смерти. Деньги есть очень хороший сдерживающий фактор для заказчика, поэтому стоит давить именно на деньги. У нас в команде эстимейты выставляются часами, а один час стоит около 30-40 долларов. Заплатить 100 долларов за фотографию или лишний и очень бесполезный чекбокс? Да пожалуйста, сколько хотите! Любой каприз, но деньги заплатите. Вот так и живём. К сожалению, многие клиенты очень этим недовольны и некоторые вещи действительно можно и сделать бесплатно. Но это уже чисто индивидуально по отношению к клиенту, основываясь на том, какой он человек и с чем его едят. Иногда под хорошего клиента и прогнуться можно, но ни в коем случае никому нельзя давать намёка на то, что вы будете делать бесплатно.

Эпизод VI: «Возвращение к статейкам»


После прохождения через все эти круги разработки у заказчика иссякают идеи(в конце у вас получается какой-нибудь коммерческий проект с API, SDK, модулем для magento и woocommerce, двумя репозиториями на гитхабе и разработанным дизайном для кружки. Больше уже ничего не сделать. Остаётся только читать статьи до следующего проекта. С ужасом вспоминая времена становления компании, когда вы брали любые фриланс-проекты у всех подряд(даже у украинцев), и с наслаждением снова и снова рассматривать новый готовый проект, сделанный для какого-нибудь американца.

Небольшие советы для разработчиков: всегда очень долго, нудно и кропотливо разбиратей с заказчиком ТЗ. Пусть он напишет туда всё, что хочет и за всё заплатит. Только так и никак иначе. Потом начнется «я вот вам когда-то сказал, вот мы по скайпу говорили и вы сказали, что можно лалала». Только ТЗ.
Небольшие советы для заказчиков: в большинстве случаев вы сами не знаете, чего хотите. Наша компания представляет услугу по обработке ТЗ. Не бесплатно, как могло показаться, а за деньги. Просто эту сумму вы разбиваем в почасовку, когда просим какие-то деньги. Советую долго, нудно и кропотливо обсуждать ТЗ с вашими разработчиками, или же нанять программиста, который поможет составить вам уже готовое ТЗ основываясь на ваших идеях.

Спасибо за внимание!

P.S. Ничего личного к украинцам не имею, просто статистически проекты с заказчиками из жовто-блакитной проходят хуже всего. Прошу прощения, если вдруг кто-то оскорбился. Будем пить пиво и со смехом вспоминать все былые обиды.
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 34

    +6
    Ненавижу работать по фиксированному тз. Это никогда не работает для проектов с разработкой более 2 недель.

    Советую присмотреться к DDD
      +2
      Я так понимаю ТЗ и DDD не конфликтуют, скорее они коррелируют друг с другом. ТЗ можно использовать для описания предметной области и разруливания связей между объектами, для программиста это наверное самое главное, вникнуть в предметную область, понять что хочет заказчик.
      Поэтапная разработка предполагает постоянное допиливание ТЗ, просто это допиливание строго регламентировано, прошел спринт, покрыли тестами, сдали, допиливаем ТЗ по новым фичам, новый спринт и т.д.

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

        А иначе выяснится, что то, на что вы угробили несколько сот человеко-часов… было просто «пожеланием», за которое заказчик, так и быть, долларов 20-30 готов отвалить.
          0
          Выступал заказчиком несколько раз, и по-моему опыту — ТЗ это лишь список основных функций (1, 2, 3) проекта, возможно с некими эскизами дизайна форм или отчетов. ТЗ практически никогда не описывает поставленную задачу исчерпывающе, если там, конечно, не задание на разработку калькулятора или ТЗ не стоит как половина стоимости всей разработки.
          Когда дело доходит до контроля тех или иных этапов, выполняемых по ТЗ, довольно часто оказывается, что если ТЗ не 100+ страничный документ, что исполнитель/команда исполнителей не так поняла или интерпретировала те или иные пункты из ТЗ. Иногда бывает, что исполнитель не может выполнить один-в-один как написано в ТЗ, в связи с техническими ограничениями, тогда идет согласование между тем, что хотелось и тем, что получилось (и приведение этих двух вещей к общему знаменателю).
          "… поднимает базу, если та падает, делает мелкие фиксы. Если намечается хоть какой-нибудь мало-мальски большой баг — сразу в эстимейт..." т.е. баг команды, в отличие от фич заказчика, также должен быть оплачен заказчиком? Оригинально.
            +2
            >> баг команды, в отличие от фич заказчика, также должен быть оплачен заказчиком? Оригинально.
            Именно так, и никак иначе.
            Именно в этом состоит послегарантийная техподдержка.
            Вам же телевизор никто не будет бесплатно чинить после истечения гарантии.
            Другое дело, что может быть фиксированная оплата техподдержки, где есть обязательство обеспечить функционирование системы, и неважно, какой трудоемкости требует исправление критических багов.
              0
              Распространенное заблуждение. Исполнители часто путают работу над проектом с продажей коробочной версии продукта. Телевизор же собирается не по ТЗ заказчика, а является продуктом разработки, тестирования и массового производства. Это как купить лицензионную ОС Windows, а потом платить Microsoft за каждый патч.
                0
                Вы во многом правы, но в реальности получается так, что есть какой-то гарантийный бесплатный период поддержки (у нас это 1 месяц), за который заказчик и реальные пользователи (продакшн) должны по-идее выявить основные баги. Далее поддержка естественно платная, у нас по модели Time&Materials (оплата за часы).
                  0
                  Простите, но у Вас явное противоречие, приводите пример для коробочного продукта с бесплатными патчами (которые заканчиваются, см. XP), возражая против платной техподдержки разработанного по ТЗ.
                  Придется рассказать азы.
                  Заказчик после процедуры сдачи продукта подписывает акт приемки.
                  Затем начинается период гарантийной техподдержки.
                  После истечения которого все работы по продукту платные, в т.ч. исправление багов, а, точнее, обеспечение функционирования продукта в рамках ТЗ.
                  Все отступления от этого — добрая воля разработчика и/или прогиб под заказчика.
                0
                если там, конечно, не задание на разработку калькулятора или ТЗ не стоит как половина стоимости всей разработки
                Вообще-то исчерпывающее ТЗ, выстраданное, осмысленное и принятое Заказчиком — это считайте половина проекта. Просто не получится Заказчику объяснить что это стоит половину денег. Да и Исполнитель не всегда это понимает.

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

              Помню, кстати, один случай, когда мы работали не напрямую с заказчиком, а с его заместителем. И он где-то попросил сделать какую-то ненужную хрень, а мы взяли и сделали. А когда пришло время сдавать проект, ему крайне не понравилась эта вещь, и он ругался, кричал, обзывался и отказывался платить. Мы ткнули его лицом в то, что это было зафиксировано в документе, мол, к нам никаких претензий, ваш представитель попросил и на наши просьбы передумать он нам ответил, что инфа сотка, дирик будет в восторге ёпт. Ну и ткнули лицом в ТЗ и e-mail логи, сказали, извините — но платите, люди же работали. Таки заплатил, до сих пор работаем с ним, правда, часть задач он перевёз в Индию.
                0
                Кстати, на счёт DDD спасибо)
                  0
                  По неопытности была похожая ситуация, только более абсурдная и сложилось все несколько иначе.
                  Работали не на прямую с заказчиком, а с представителем, утвердили ТЗ и сроки. Идет работа над дизайном сайта, вносятся правки, все вроде бы как обычно. Сайт уже сверстан, настраиваются последние штрихи и вдруг возникает сам заказчик и говорит: «Ваш дизайн говно, переделывайте».
                  Никакие доводы не были услышаны, в итоге заказчик без сайта, мы кое-как вышли в ноль.
                    0
                    Как то была обратная ситуация. Делали лет 6-7 назад сайт для «дочки» одной компании. У головной компании — брендбук, где листов 100 посвещено сайту. Какие шрифты, какие цвета, какие отступы от картинок и пр. Как должны оформляться новости/галереи и т.д. Шикарная штука.
                    Когда непосредственный заказчик просил вкорячить очередную фичу в проект — с него требовалось письмо официальное, что он по своей инициативе отступает от общих требований группы компаний и либо согласовал это, либо берёт на себя всю ответственность. В итоге 99% «хотелок» удалось таким образом завернуть.
                  +1
                  Вопрос к автору: Такая схема работы на какие сроки и на какие деньги? У меня сложилось впечатление, что речь идёт о проектах типа дизайна домашней странички. А если проект на год?
                    +3
                    Наш самый большой проект мы поддерживаем уже пятый год. Просто мы разделяем его на миллион подпроектов и к каждому пишем спецификацию.
                    +4
                    А на каком этапе заказчик понимает стоимость разработки? Вы оценки проводите только на третьем этапе, а мне почему-то всё время попадаются клиенты, которым надо стоимость ещё дна нулевом этапе.
                    • UFO just landed and posted this here
                        +1
                        А другие денег не считают? И нет, я не говорю про СНГ.
                        • UFO just landed and posted this here
                            +4
                            По моему опыту первое что хочет знать заказчик — это стоимость, второе — срок. И это в любой стране.
                            Дилетантство как правило проявляется в непременном желании узнать эти две вещи без постановки задачи, круглые глаза в ответ на сумму и конечно решения вроде «знакомый Вася это сделает за сто баксов и неделю».
                            • UFO just landed and posted this here
                              0
                              Золотые слова!
                                0
                                Не знаю, о каких Вы бизнесах говорите и почему сразу говорите о дилетантстве. Я не так много компаний видел, конечно, но все они плевали на издержки и всё вкладывали в развитие новых клиентов. Но это в Москве. Может быть в Махачкале, всё иначе.
                                Выбор модели поведения бизнеса зависит больше от рынка и от размера самой компании. Серебряной пули, как всегда нет и любому бизнесу приходится балансировать между сокращением издержек и ростом.
                            0
                            На этапе выставленного приблизительного времени разработки. Каждая задача оценивается.
                              0
                              Лично у нас практикуется понятие «предварительных оценок». Как правило это «вилка» по срокам и бюджету, которую мы формулируем после составления первого документа проекта, который нахываем «бриф» (BSD). По моему опыту для любого адекватного заказчика на первом этапе этого более чем достаточно. Если же требуют точных и итоговых оценок до этапа проектирования и написания ТЗ, то лучше с таким заказчиком вовсе не связываться.
                              +1
                              Как вы делаете эстимейт, если заказчик хочет сайт «как у Васи»? То есть он еще не решил работать с вами или нет, а только приценивается. Насколько четко вы укладываетесь в эстимейты? Что делаете, если потратили больше времени, чем планировали?
                                +7
                                О, вы подняли один из важнейших вопросов всего фриланса! Ответ на него прост: вы врете, и надеетесь что ваше вранье будет искуплено реальными сроками, совпадшими с ним. Конечно, если клиент готов к большим срокам, которые нивелируют неопределенность, то вы называете большой срок. Но клиент как правило не готов. Так что вы либо врЁти, либо работаете с теми кто от вас врать не требует.
                                  +3
                                  Господа минусющие, если вы покажите мне способ называть сроки моментально на основании неполной информации, и так чтобы они отвечали истине(не были враньем), то я вас с радостью выслушаю.
                                    0
                                    Есть другой вариант: называете вилку цен и вилку сроков. Далее идет уточнение и сужение вилки. Если заказчик не знает чего хочет, и не понимает зависимости времени и цены от сложности, то с ним лучше не работать.
                                    • UFO just landed and posted this here
                                        0
                                        Насколько я понимаю, в этой ветке ведется обсуждение постановки задачи вида: «сайт как у дяди Васи» с последующим точных соблюдением изначальных оценок. Ни о каком ТЗ здесь и речи не идет) PerlPower совершенного справедливо заметил, что в таком положении любой эстимейтор фактически вынужден солгать, потому что в реальности слишком мало информации, чтобы была хоть малейшая вероятность выдать точную оценку.
                                    0
                                    К счастью, когда я пришёл работать в компанию, то она уже переросла «фриланс-на-снг» и теперь занимается «фринлансом-на-юса».
                                    Но если бы такое случилось, то выставили бы неадекватный ценник, а потом натянули бы шаблон на CMS. Такие дела.
                                    0
                                    «все фичи из третьего пункта будут неадекватно заэстимейчены» — достойно плаката :-)

                                    Only users with full accounts can post comments. Log in, please.