Представьте, что вы заказываете строительство загородного дома. Вы утвердили проект, согласовали материалы, строители залили фундамент, возвели стены и уже приступили к крыше. И тут вы замечаете, что окно в спальне расположено на полметра левее, чем вам представлялось.
Вы просите строителей передвинуть окно, они останавливают работы, вызывают бригаду, переделывают кладку. Проходит неделя, и вам выставляют счёт за дополнительные работы. Вы удивлены: «Я же просто попросил передвинуть окно, это же мелочь!»
В разработке программного обеспечения такие ситуации возникают на каждом шагу. Заказчик просит «чуть-чуть подвинуть кнопку», «сделать шрифт немного жирнее» или «поменять местами два пункта меню».
Когда разработчик сообщает, что эта правка займёт время и потребует дополнительной оплаты, начинается конфликт: заказчик считает, что его пытаются развести на деньги. Разработчик же считает, что его труд обесценивают. Начинается то, что можно назвать войной правок.
Эта война похожа не на открытые боевые действия, а тихий конфликт, который тлеет внутри проекта. Заказчик копит недовольство и думает, что подрядчик специально накручивает часы, подрядчик копит усталость и думает, что заказчик сам не знает, чего хочет. В результате страдает продукт, срываются сроки, отношения портятся.
Мы много лет занимаемся разработкой программного обеспечения и через это прошли не один раз, мы научились смотреть на ситуацию глазами заказчика, поэтому в этой статье расскажем, почему даже микроскопическая правка в интерфейсе может стоить денег и занимать время, почему нельзя просто взять и передвинуть кнопку за пять минут, даже если кажется, что это элементарно.
И главное – как выстроить процесс работы с изменениями так, чтобы и заказчик получал то, что хочет, и разработчик не работал бесплатно, и продукт в итоге становился лучше, а не превращался в бесформенную свалку правок.
Маленькие правки и большой урон
Когда заказчик просит «просто передвинуть кнопку», в его голове эта операция выглядит элементарно. Ну правда, что там делать? Открыл файл, изменил пару цифр в коде, закрыл файл. Однако реальный процесс выглядит совершенно иначе, и чтобы понять это, нужно заглянуть внутрь того, как вообще устроена современная разработка.
Любая программа, будь то сайт, мобильное приложение или сложная корпоративная система, состоит из множества слоёв. Кнопка, которую видит пользователь, – это только верхушка.
Под ней находится вёрстка, которая определяет внешний вид, ещё глубже – программная логика, которая привязывает к кнопке конкретные действия, а вокруг всей этой конструкции существуют стили, скрипты, библиотеки и настройки, которые влияют на работу других элементов.
Теперь представьте, что разработчик получает задачу «сдвинуть кнопку на 10 пикселей влево». Первое, что он делает, – открывает программный код и находит тот самый фрагмент, который отвечает за положение кнопки. Звучит просто, но в проекте, который разрабатывался год, таких фрагментов могут быть тысячи, поиск нужного места уже занимает время.
Допустим, разработчик нашёл нужную строчку и изменил координаты, теперь нужно проверить, как это изменение повлияло на другие элементы интерфейса. Часто бывает так: кнопку сдвинули влево, она наехала на другую кнопку или закрыла текст, это называется эффектом бабочки – маленькое изменение в одном месте порождает цепочку проблем в других.
Следующий этап – проверка адаптивности: сегодня люди заходят в программы с телефонов, планшетов, ноутбуков и больших мониторов. То, что красиво выглядит на широком экране разработчика, может развалиться на маленьком экране смартфона, поэтому разработчик обязан проверить, как сдвинутая кнопка ведёт себя на всех типах устройств. Иногда для этого нужно запускать эмуляторы или подключать реальные телефоны.
Дальше нужно убедиться, что кнопка по-прежнему работает: казалось бы, положение кнопки не влияет на её функцию, однако в современных интерфейсах расположение элемента может быть жёстко связано с программными обработчиками событий. Бывает, что при изменении координат кнопка перестаёт реагировать на нажатия или нажимается не там, где нужно.
После того как разработчик всё проверил, наступает очередь тестировщика: он должен пройти по всем сценариям использования, убедиться, что ничего не сломалось, и только после этого дать добро на передачу заказчику. Если тестировщик находит ошибку, задача возвращается разработчику, и цикл повторяется заново.
Но самая дорогая часть любой правки – переключение контекста. Разработчик в течение дня решает сложные задачи, погружён в код, держит в голове множество деталей. Внезапный запрос на «передвинуть кнопку» вырывает его из этого состояния. Он отвлекается, переключает внимание на мелочь, потом пытается вернуться к основной работе.
Исследования показывают, что после такого отвлечения человеку требуется от пятнадцати до тридцати минут, чтобы снова погрузиться в сложную задачу с той же глубиной. Это время не фиксируется в отчётах, но оно влияет на общую скорость разработки и, в конечном счёте, на стоимость проекта.
Получается, что за видимой простотой задачи «передвинуть кнопку» скрывается целый производственный процесс: поиск нужного места в коде, внесение изменений, проверка влияния на соседние элементы, адаптация под разные экраны, функциональное тестирование, исправление возможных ошибок и неизбежные потери на переключение внимания.
Каждый из этих этапов требует времени и квалификации человека, а значит, имеет свою цену, поэтому когда разработчик называет стоимость такой правки, он оценивает не пять минут на изменение двух цифр, а весь комплекс работ, который за этим стоит.
Какими бывают правки и кто за них платит?
Чтобы перестать спорить о том, должна ли правка делаться бесплатно или за деньги, нужно договориться о правилах игры. В разработке программного обеспечения все изменения принято делить на три категории: разница между ними огромная, и от того, к какой категории относится правка, зависит и срок её выполнения, стоимость и сам факт её появления в ближайших планах работы.
Первая категория – это ошибки.
В мире разработки ошибкой считается ситуация, когда программа работает не так, как было задумано и записано в документации. Если в техническом задании чёрным по белому написано, что при нажатии на кнопку открывается окно с формой обратной связи, а на самом деле ничего не происходит – это ошибка. Если форма должна отправлять письмо на почту менеджера, а письмо не приходит – это тоже ошибка.
Ошибки – это гарантийный случай: обычно в договоре между заказчиком и разработчиком прописывается гарантийный срок, в течение которого все обнаруженные ошибки исправляются бесплатно.
Логика здесь простая: вы заказали работающий продукт, продукт работает неправильно, значит, подрядчик не доделал свою работу и должен это исправить за свой счёт. Никаких споров тут возникать не должно, если, конечно, обе стороны честно понимают, что считать ошибкой.
Вторая категория – это доработки.
Доработкой называется ситуация, когда программа работает ровно так, как договаривались, но заказчику этого показалось мало. Например, кнопка нажимается, форма отправляется, письмо приходит, всё по документации, но заказчик говорит: «А давайте сделаем, чтобы после отправки формы всплывало красивое окошко с поздравлением и картинкой».
Доработки – это новая работа, в документации этого не было, в макетах не рисовали, в стоимость проекта это не закладывали, поэтому доработки оплачиваются отдельно. И это справедливо: никто не требует от строителя, чтобы он бесплатно пристроил к дому второй этаж только потому, что заказчику вдруг захотелось больше пространства.
Третья категория – это изменения требований.
Это самый сложный и спорный вид правок. Изменение требований возникает тогда, когда программа работает правильно, никаких новых возможностей не добавляется, но заказчик просит сделать то же самое, но по-другому.
Классический пример: в техническом задании написано, что кнопка входа находится в правом верхнем углу, разработчик её там разместил, всё работает. Приходит заказчик и говорит: «Знаете, я посоветовался с дизайнером, мы решили, что вход должен быть не справа, а слева. И не в углу, а в центре шапки. И не кнопкой, а ссылкой».
С одной стороны, это не ошибка – программа работает по документации, с другой стороны, это и не доработка в чистом виде, потому что никакого нового функционала не добавляется, просто меняется расположение уже существующего элемента. Как поступать в таких случаях?
Здесь всё зависит от того, на каком этапе возникло изменение: если изменение требований происходит на этапе, когда проект ещё в разработке и до сдачи далеко, это обычно решается через приоритеты. Разработчик может пойти навстречу и сделать изменение бесплатно, но тогда какие-то другие задачи сдвинутся по срокам, либо заказчик доплачивает за срочность, и задача выполняется вне очереди.
Если же изменение требований возникает после того, как работа уже принята и оплачена, это практически всегда считается отдельной задачей и оплачивается как доработка, потому что разработчик уже отчитался за результат, получил деньги и переключился на другие проекты. Возвращаться к старому и переделывать по новым требованиям – это значит тратить время, которое могло быть потрачено на другую работу.
Самое важное здесь – чётко определить на старте проекта, что мы считаем ошибкой, что доработкой, а что изменением требований. Обычно эта договорённость фиксируется в документе, который называется «порядок приёмки работ». В нём прописываются критерии: при каких условиях задача считается выполненной, что именно проверяется при сдаче, сколько времени даётся на проверку и как классифицируются замечания.
Если такой договорённости нет, начинается та самая война правок: заказчик любую свою новую мысль считает ошибкой, которую должны исправить бесплатно, разработчик любую просьбу считает доработкой, за которую нужно платить. Обе стороны искренне уверены в своей правоте, и найти выход из этого тупика без потерь уже почти невозможно.
Как избежать войны между заказчиком и командой?
Многолетний опыт разработки программного обеспечения показывает, что конфликтов вокруг правок можно избежать почти полностью. Для этого не нужно нанимать специального человека или покупать дорогое программное обеспечение, достаточно ввести несколько простых правил, которые касаются того, как формулируются задачи, как они принимаются, как накапливаются и как передаются в работу.
Первое правило касается чёткого определения момента, когда задача считается выполненной. В профессиональной среде это называют критериями приёмки. Звучит сложно, но на деле это просто список условий, при которых задача закрывается и принимается заказчиком.
Допустим, в задаче написано: «Добавить форму обратной связи на страницу контактов». Что значит «добавить»? Для одного заказчика это просто появление полей для ввода имени и текста сообщения, для другого обязательно нужна капча, чтобы не пробивали спамом, третий хочет, чтобы письмо дублировалось в CRM.
Если все эти требования не записаны в задачу изначально, конфликт неизбежен. Разработчик сделает форму, заказчик скажет: «А где капча?», разработчик ответит: «А про капчу не было речи». Заказчик настаивает, что это и так подразумевалось.
Поэтому правило номер один: перед тем как задача уходит в разработку, заказчик и разработчик вместе записывают список того, что будет проверяться при сдаче.
Второе правило касается порядка передачи правок в работу: очень часто заказчики пишут в мессенджер: «Слушайте, тут такая мелочь, сделайте по-быстрому, пока горячо». Разработчик отвлекается, бросает текущие задачи, делает эту мелочь, отправляет заказчику. Через час приходит следующая «мелочь», потом ещё одна. В итоге плановая работа стоит, команда мечется как угорелая, а заказчик уверен, что всё делает правильно.
Чтобы этого избежать, вводится простое правило: ни одна правка не выполняется в тот момент, когда она поступила. Исключение делается только для ситуаций, когда программа полностью встала и не работает совсем – это критическая ошибка, требующая немедленного вмешательства.
Все остальные пожелания, даже самые срочные и важные, записываются в отдельный список. Этот список называется общим перечнем задач: в нём живут все хотелки, все пожелания, все «вот бы ещё добавить» и «надо бы поправить». Заказчик может добавлять туда что угодно в любое время, но выполнение задач из этого списка происходит не в порядке поступления, а по результатам плановых встреч.
Такие встречи лучше всего проводить раз в месяц или раз в две недели, в зависимости от интенсивности разработки. На встречу приходят заказчик и руководитель разработки, они открывают общий перечень и смотрят, что там накопилось.
Этот простой ритуал решает сразу несколько проблем:
- Во-первых, разработчики перестают дёргаться на каждый чих и могут спокойно работать.
- Во-вторых, заказчик видит, что его пожелания не игнорируют, а просто ставят в очередь.
- В-третьих, появляется возможность сравнивать задачи между собой и выбирать действительно важные, а не те, которые громче всех кричат.
Третье правило касается частоты показов промежуточных результатов. Чем реже заказчик видит продукт, тем дороже обходятся правки. Показывать результаты нужно как можно чаще, в идеале – каждые два-три дня.
Заказчик заходит в работающую программу, смотрит, как реализована та или иная задача, и говорит: «Вот здесь кнопка должна быть не слева, а справа». Разработчик прямо при нём правит код, и через пять минут кнопка уже справа. Это стоит копейки, потому что вокруг кнопки ещё ничего не выстроено, она висит в воздухе.
Если же эту же правку заказчик попросит через месяц, когда кнопка обросла логикой, проверками, аналитикой и стилями, стоимость будет совсем другой. Поэтому правило «чаще показывать» выгодно обеим сторонам. Заказчик получает возможность влиять на продукт на ранних стадиях, разработчик экономит время на переделках.
Четвёртое правило касается объединения мелких правок в пакеты. Даже если наладить регулярные показы и плановые встречи, всё равно останутся мелкие замечания: «буква в слове криво написана», «цвет чуть-чуть не тот», «отступ великоват». Запускать разработку ради каждой такой мелочи – всё равно что вызывать бригаду строителей, чтобы заменить одну перегоревшую лампочку.
Поэтому все мелкие правки собираются и отдаются одним пакетом, допустим, раз в две недели. Разработчик выделяет полдня, быстро пробегается по списку, исправляет все опечатки и недочёты, и выкатывает общее обновление. Заказчик видит, что его замечания учтены, разработчик не тратит время на постоянные переключения.
Пятое правило касается подготовки к работе. Самая дешёвая правка – та, которую заметили на бумаге. Чем детальнее проработан внешний вид программы до того, как началось программирование, тем меньше споров возникает потом.
Есть такой подход: сначала рисуется внешний вид каждой страницы, каждого окошка, каждой кнопки. Эти картинки согласовываются с заказчиком до мельчайших деталей. Заказчик смотрит и говорит: «Здесь кнопка должна быть не зелёная, а синяя». Дизайнер нажимает несколько клавиш, и кнопка становится синей.
И только когда все картинки утверждены и заказчик сказал «да, именно так я это и вижу», начинается написание кода. Тогда правок почти не возникает, потому что всё уже обсудили и проверили на берегу.
Действия, если конфликт уже начался
Даже если на старте проекта были прописаны все правила, а заказчик и разработчик искренне старались их соблюдать, конфликты всё равно случаются. Люди устают, сроки горят, бюджеты тают, нервы сдают, война правок может вспыхнуть в любой момент, и важно понимать, как из неё выходить с минимальными потерями для обеих сторон.
Первое, что нужно сделать, когда конфликт уже разгорелся, – остановиться и остыть. Ни одно важное решение не должно приниматься в тот момент, когда стороны повышают голос или обмениваются колкостями в мессенджере. Лучшее, что можно сделать, – взять паузу. На день, на два, на выходные. За это время эмоции улягутся, и можно будет вернуться к разговору в спокойном состоянии.
После паузы нужно собрать все документы, переписки и договорённости, которые были достигнуты ранее: техническое задание, протоколы встреч, письма, где согласовывались детали, список критериев приёмки. Всё это ложится на стол, дальше начинается спокойный и честный разбор того, что именно пошло не так.
Очень часто оказывается, что конфликт возник из-за того, что стороны по-разному поняли одни и те же слова. Заказчик был уверен, что фраза «форма обратной связи» подразумевает автоматическую отправку письма менеджеру. Разработчик считал, что форма просто собирает данные и показывает их администратору при входе в систему. В документации этот момент был пропущен или описан недостаточно чётко.
В такой ситуации нет правых и виноватых, есть просто недоразумение, которое теперь нужно исправлять. Лучший способ – сесть и договориться, как выходить из положения. Разработчик может взять часть работы на себя, заказчик может доплатить за оставшуюся часть. Главное – чтобы обе стороны чувствовали, что к ним прислушались и пошли навстречу.
Иногда конфликт возникает из-за того, что заказчик уверен: его правка – это ошибка, которую должны исправить бесплатно, а разработчик уверен: это доработка, за которую нужно платить. Здесь помогает возврат к тем самым трём категориям, о которых мы говорили в прошлой главе. Открывается документация, смотрится, как была описана исходная задача.
Если кнопка должна быть зелёной по документации, а она зелёная, то просьба сделать её синей – это доработка, какой бы простой она ни казалась. Если кнопка зелёная по документации, а на самом деле она серая – это ошибка.
Если документация составлена плохо или какие-то моменты в ней вообще не прописаны, приходится договариваться по справедливости. Обычно в таких случаях работает принцип «встречного движения». Разработчик делает правку бесплатно, но заказчик соглашается перенести на более поздний срок какую-то другую задачу из текущего спринта. Или разработчик делает скидку на эту правку, но заказчик подписывает акт о том, что все предыдущие работы приняты без замечаний.
Бывают ситуации, когда конфликт зашёл уже слишком далеко: стороны перестали доверять друг другу, каждое слово воспринимается в штыки, совместная работа становится невозможной. В таком случае лучший выход – пригласить третью сторону: независимого эксперта, который разбирается в разработке, но не участвовал в проекте.
Такое решение стоит денег, но часто это дешевле, чем продолжать войну, тратить время юристов и портить отношения. К тому же, мнение независимого эксперта обычно принимается обеими сторонами, потому что он не заинтересован в том, чтобы поддерживать кого-то одного.
Ещё один важный момент, который помогает гасить конфликты, – умение слушать. Часто за требованием «просто передвинуть кнопку» стоит какая-то более глубокая потребность. Заказчик не объясняет её, потому что сам не всегда её осознаёт, или потому что считает, что это и так понятно. Задача разработчика – не просто кивать и принимать правки к исполнению, а пытаться понять, зачем заказчику это нужно.
Допустим, заказчик просит передвинуть кнопку в другой угол. Разработчик спрашивает, выясняется, что на эту кнопку плохо нажимают пользователи, она теряется на фоне другого содержимого. Тогда вместо простого передвижения можно предложить более серьёзное решение: изменить цвет, добавить тень, увеличить размер. Заказчик получает не просто передвинутую кнопку, а растущее число обращений. Конфликт исчерпан, потому что настоящая потребность удовлетворена.
Война правок заканчивается тогда, когда обе стороны понимают: совместная работа выгоднее, чем конфликт. Если это понимание есть, можно договориться о чём угодно. Если его нет, никакие инструменты и правила не помогут.
Разработка ПО от 66 Бит
Всего за 10 минут вы узнали почему маленькая правка может нанести бизнесу огромный урон и как избежать их появления.
Мы в 66 Бит, имея большой опыт коммуникации с руководителями самых разных компаний, уверены в успехе вашей будущей системы и предлагаем помощь в анализе, проектировании и разработке продуктов разного уровня сложности и технологий. Подробнее читайте на нашем сайте!