Недавно обсуждали мы в группе CMS Magazine & «Рейтинг Рунета» один документ, и Юрий Новосад упомянул там подход под названием Getting Real. Стало как-то мне стыдно за то, что я о нем подробной информацией не владею, не поленилась за выходные прочесть соответствующий первоисточник. Тем, кто знает аглицкого языка, очень рекомендую читать именно на нем, ибо тому, кто переводил надо просто руки оторвать :). Но не суть. А суть в том, что к большущему своему удивлению, я обнаружила, что наш Webway уже годы и годы использует множество постулатов этого самого Getting Real. Вот и пришло мне в голову изложить, как именно мы его используем (и как не используем), вдруг, кому пригодится. Также буду крайне благодарна, если кто-то из читателей-коллег по цеху, чиркнет пару строк на тему своего опыта. Сразу предупреждаю, что это рассказ о реальном опыте реальной маленькой компании, а не рекомендации для всех на все случаи жизни.

Итак, мы исходим, в первую очередь, из того, что хочет клиент. Что же из этого следует?

1. Сначала дизайн, потом ТЗ. Авторы метода рекомендуют начинать разработку с экранных форм, которые помогают понять, как ЭТО будет работать без предварительного геморроя с разработкой спецификаций и подробных ТЗ. Отличие нашей компании от авторов в том, что наш клиент в большинстве случаев хочет не функциональное ПО, а красивый сайт, он хочет понимать не только, как он функционирует, но как он выглядит Поэтому мы начинаем не с рабочих экранов, а прямо с дизайна. Всегда. Мы категорически не пишем ТЗ до того, как разработаем дизайн главной страницы и вместе с клиентом не поймем, как все будет выглядеть. Подход некоторых компаний, которые сначала пишут ТЗ, а только затем начинают рисовать, у нас не давно отвергнут, потому что описать то, что не видишь крайне тяжело, а главное бесполезно. А тыкать потом клиента носом в то, что, посмотрев картинки, он решил отойти от ТЗ, мы тоже не любим — вредно это для настроения клиента и пользы общего дела. Рисовать некий прототип дизайна (схему) тоже довольно бесполезно, ибо большинство схем сводятся к форме вида «меню слева, шапка сверху». Есть мнение, что дизайн невозможно создать без четкой ТЗ-образной постановки задачи и даже точного контента. Мы против. Мы считаем, что единственное, что нужно для дизайна — понимание целей клиента. Разумеется, невозможно отрисовать все страницы сайта без ТЗ (например, отрисовать каталог без знания, какие в нем хотя бы товарные группы). Поэтому ТЗ нужно, но не сразу и не жестко. В нашей практике вполне допустима коррекция ТЗ по итогам утверждения дизайна. Когда клиент видит, как будет выглядеть сайт, ему гораздо проще принимать решения, чем когда он читает ТЗ. Для нас это очевидно. [Почему бы вообще не отменить ТЗ? Потому что у клиентов нет чувства меры, и прикрывать свою задницу договором и ТЗ так или иначе приходится. Мало того, чересчур клиенториентированный подход клиента портит :). Он считает, что раз уж мы в течение проекта периодически идем ему навстречу, то никаких ограничений нет. Но тема аццких клиентов — тема отдельная]. 
    
2. Большинству клиентов нужна простая ЦМС. Только редактирование текста и ограниченные возможности управления структурой. Больше ничего. Никаких диких функций и инструкций для разработчика. Никаких красивых объемных кнопок, отбрасывающих тень и тормозящих работу. Никаких дурацких настроек. Даже функции редактирования ограничены. Из своей ЦМС мы устранили все функции, которые (а) могут испортить проект или (б) осложнить жизнь нам и клиенту. Чем проще ЦМС, тем проще и дешевле для клиента техподдержка, тем дешевле хостинг, тем короче сроки разработки. Мы сделали ЦМС так, что она вообще не требует обучения на стороне клиента, мы сделали ее так, что она позволяет нашим разработчикам делать проекты максимально быстро (это — не реклама, это — факт). Мы много лет говорили клиенту «нет» на просьбы об усложнении ЦМС — мы не добавили дополнительные функции в текстовый редактор, мы не сделали красивый дизайн, мы не пишем длинных инструкций, потому что на самом деле это не нужно никому — ни нам, ни клиентам. Мы глухи когда слышим что-то типа — эта функция должна быть у каждой нормальной ЦМС. Зачем? Вы хотите сайтом управлять или универсальный конструктор на все случае жизни? Нужна ЦМСка с максимумом функций, берите коробку. Разработка будет дольше, техподдержка дороже, обучение геморройнее, зато сколько красивых кнопок и потенциальных возможностей! 
    
3. Клиенту нужно, чтобы доработки делались быстро, даже если они не такие уж мелкие и в принципе требуют отдельного ТЗ, которое клиент сам не в состоянии сформулировать. Мало того, клиент вообще склонен фантазировать по ходу работы. Поэтому мы давно перестали заморачиваться тем, чтобы оценивать каждую работу отдельно по часам, а потом объяснять клиенту, что из-за новых пожеланий все надо пересчитывать. Мы решаем проблемы таких клиентов поддержкой за абонентскую плату, во время которой в один месяц можно сделать чуть меньше, в другой чуть больше и бесконечное количество раз переделать одну и ту же вещь по ходу дела. 
    
4. У нас минимальное число сотрудников. В определенные периоды времени мы умудрялись сдавать по 4 проекта в месяц, имея в штате всего одного программиста, двух верстальщиков, одного дизайнера и ни одного менеджера проектов (менеджеры проектов — вообще отдельная тема, про которую расскажу в отдельной заметке про KPI). При этом успевали мы вовремя, и качество не страдало. Как? Благодаря своей ЦМС, в основном. [Знаете когда эта малина закончилась, и нам пришлось искать дополнительных людей и аутсорсеров, а также нарушать сроки? Когда клиенты вбили себе в голову, что коробочные супер-ЦМС лучше. В итоге не только нам стало тяжелее, но и клиентам, т.к. они кучу времени тратят на приемку проекта из-за того, что не могут научиться пользоваться ЦМСкой и нормально выложить контент. Если Вы никогда не разрабатывали собственной ЦМСки и сразу стали пользоваться коробками, Вам этого не понять :)]. У нас всего один сервер для сотен проектов, который работает безотказно. Всего один сотрудник техподдержки на полсотни клиентов. Мы нанимаем людей только, когда возникает острая необходимость, и то не сразу, сначала проверяем нельзя ли без них обойтись имеющимися силами. Даже когда кто-то уходит из компании, мы сразу не начинаем искать замену, сначала смотрим, как пойдет без него. Вы можете удивиться, но иногда идет лучше :). Если ушедший является руководителем, то мы всегда растим смену из имеющегося сотрудника, а не берем нового со стороны (про это тоже расскажу в отдельной заметке про KPI). [Единственным исключением являются секретарь и курьер. Это две должности, без которых мы не можем жить, и от отсутствия которых хотя бы один день компанию начинает лихорадить :) ] Мы НИКОГДА не берем на работу ГУРУ, эдаких опытных «дедов». «Дед» — это не возраст, это офигенный опыт и свое видение всего вокруг :). Я всерьез верю, что наем готовых гуру — самый бесперспективный путь найма сотрудников в маленькие компании. При найме мы никогда не верим резюме и смотрим на него сквозь пальцы. Мы берем на менеджерские должности людей без опыта работы, если у них светлая голова. Меня искренне потрясают компании, которые, делая примерно то же, что мы, и примерно в том же объеме имеют в 2-3 раза больше сотрудников. Это ж какие издержки! Это ж какие цены, чтобы всех содержать! Это ж сколько бездельников! :) А если они не бездельники, а заняты высокоумственным трудом, то где результаты в виде мировых открытий?
    
5. Мы четко следуем критерию «если хочешь, чтобы дело было сделано хорошо, доверь его самому занятому сотруднику», т.к. именно он работоспособен и доводит дела до конца.

Но есть у Getting Real и то, что нам категорически не подходит. Например, понимание, что самая дорогая часть проекта — программирование. Авторы метода предполагают, что дизайн или html легко изменить, а вот программировать — это сложно и долго. В нашем случае (случае сайтов) дизайн — очень сложная часть, а верстка с каждым готом становится все сложнее из-за тучи браузеров, Apple- и Android-гаджетов. Поэтому теоретически нам проще запрограммить прототип на ЦМС без дизайна и хтмл, чем рисовать и верстать. Но, как уже было сказано выше, от программного прототипа в случае красивого, но не сложного сайта мало толку. И здесь, похоже, ничего не поделаешь.

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

А на сколько для Вас реален Getting Real?

Оригинал публикации