What to consider when starting development on a high-load system. The Top-10 mistakes made even before development starts.

What to consider when starting development on a high-load system. The Top-10 mistakes made even before development starts.

According to statistics, at the beginning of 2010, there were around 43 million Internet-users in Russia–about 37% of the country’s population. The great potential of this market, as well as its rapid growth, has led many companies to hurriedly try to fill this niche by making web-projects that will “change the world”.

For a long time, the deterring factor for entering the web-app market was the difficulty of attracting an audience. After major social networks unveiled APIs for developing applications, the threshold for entering the market reduced to a minimum. Often, the efforts of only one developer are enough for an application to attract a million users. Farm Frenzy (Весёлый фермер), for example, has demonstrated that you can earn a fair amount of money in this market, which is why people have started investing in the creation of social network applications. A similar situation has been observed in other web-projects, which have nothing to do with social networks, but which are also meant for a wide audience.

The development of Internet systems has its own quirks. If projects are managed following the old tried-and-true methods, the results will most likely be unfavorable. Additionally, many mistakes are made because project managers are poorly oriented with the technology and try to control the developers in every possible way.

In this presentation, we will examine some of the most common mistakes, the majority of which are made before development begins, with real-world examples.

Кто: Artem Volftrub
Где: HighLoad++ 2010
Когда: 25-26 October, 2010

Артём Вольфтруб: Всем добрый день! Меня зовут Артём Вольфтруб. Я работаю в компании «Грамант», руковожу разработкой. Здорово, что так много людей собралось здесь послушать мой доклад, который, по сложившейся традиции этих конференций, почему-то обозвали мастер-классом.

Как возникла идея этого доклада? Компания «Грамант», в которой я работаю, занимается разработкой, в основном это заказная разработка, – работа с внешними заказчиками. Проекты, которые мы делаем – самые разные, в основном интернет-проекты, есть финансовые системы, много систем, связанных с электронной рекламой. В результате за несколько лет работы у нас накопилось некоторое количество кейсов, которые хотелось бы представить, рассказать, почему они возникают, к каким последствиям могут привести и что с ними делать. Этот доклад ни в коем случае не «наезд» на заказчиков, это взгляд со стороны.

Первая ситуация. Классическая – когда к вам приходит заказчик, говорит, что у них есть некий проект, который надо сделать, желательно месяца за три, а лучше за полтора :-). И «вообще-то мы сами ребята опытные, но у нас своих разработчиков немного, и мы просим вас сделать этот проект, а потом мы его будем сами развивать дальше». Это нормальная, рабочая ситуация, в ней нет ничего плохого. Но, оказавшись в ней, важно понимать некоторые моменты.

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

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

И еще один важный момент. Если у вас N разработчиков, то они это сделают за 3 месяца. Если у вас 2*N разработчика, то они тоже это сделают за… 3 месяца. Есть минимальный срок разработки системы, возможно для разных команд и разных проектов он разный, но он точно не зависит от числа участников проекта.

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

Что касается передачи проекта внутренней команде заказчика. Это совершенно нормальный процесс, но чтобы смена разработчиков произошла с минимальными потерями, нужно понимать несколько простых вещей. Первое: передавать код другой команде сразу после релиза – это плохая идея, поскольку основная работа, как я уже сказал, начнётся как раз в этот самый момент, когда вы сделаете этот релиз. Второе: передавать код в виде архива исходников – очень плохая идея, поскольку в этом случае, скорее всего, система будет переписана новой командой разработчиков с нуля. При этом заказчик-то считает, что система уже готова, а психология разработчиков такова, что проще написать заново, чем разбираться в чужом коде, поэтому всё, что написано не ими, должно быть выброшено и переписано.

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

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

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

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

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

Давайте посмотрим на то, как формируются требования.

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

По нашему опыту, на момент релиза востребованными оказываются около 60% фич, которые изначально планировались и делались. Причём те самые 40%, которые оказываются не востребованы, как правило, наиболее сложные в реализации. Почему они оказываются не востребованы – отдельный вопрос, но факт остаётся фактом. А самые ценные фичи, которые наиболее востребованы пользователями – они-то в первую версию как раз и не попадают, потому что о них вы узнаёте только после релиза, получив обратную связь.

Когда вы определяете рамки проекта, очень важно установить доверительные отношения с заказчиком (это вообще один из ключевых моментов заказной разработки). Постарайтесь убедить заказчика включить в первую версию только самые нужные фичи, то, без чего реально нельзя жить. Все остальное лучше отложить до версии 2. Бета-версия – это отличный инструмент для анализа и сбора требований. Используя бета-версию, вы, фактически, интервьюируете не одного, не двух человек, а тысячу человек, и понимаете, какие сценарии реально востребованы, а какие нет. Один аналитик, даже самый опытный, не в состоянии понять это.

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

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

Когда вы продумываете архитектуру будущей системы с точки зрения масштабирования, вы должны четко понимать цель этой работы. Если это просто формальная обязательная часть коммерческого предложения, то можно открыть любую статью по теме и скопировать оттуда нужные картинки. Для того, чтобы эта работа принесла реальную пользу, нужно знать гораздо больше, чем исходное и потенциальное число пользователей системы. Более того, в большинстве случаев на столь раннем этапе практически невозможно точно спрогнозировать профиль нагрузки, выявить все узкие места. По нашему опыту самое главное – не сделать каких-то очевидных глупостей на этапе разработки первой версии системы, которые потом очень дорого обойдутся, когда вы столкнётесь с проблемами большого объёма данных или больших нагрузок. Под «глупостью» я, в частности, понимаю неправильно спроектированную архитектуру базы данных или выбор неправильных технологий для разработки приложения – то, переделка чего потребует значительных усилий в будущем.

Мы используем два критерия для оценки потенциальной нагрузки:


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

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

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

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

Это не значит, что можно писать плохой код. Это значит, что нужно действовать рационально.

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

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

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

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

Классический пример: база данных, пул фронтендов, балансировщик нагрузки. Начинаем тестировать. Как правило, для тестирования берут упрощенную комбинацию: один фронтенд, одна база данных. Начинаем нагружать систему и понимаем, что у нас фронтенд тормозит. Думаем: «ага, если у нас фронтенд тормозит, давайте уменьшим нагрузку пропорционально числу серверов, и проверим, насколько у нас хорошо всё работает». Уменьшаем нагрузку – всё хорошо. Разворачиваем в продакшене – тормозит база данных, поскольку нагрузка на нее существенно возросла. Можно пойти дальше – увеличить число фронтендов в тесте – упремся в мощность сервера базы данных, поставим мощный сервер – упремся в сеть и т.д.

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

Следующий вопрос – это вопрос отказоустойчивости. Он тоже возникает часто, все считают, что система должна быть отказоустойчивой, то есть работать при любых катаклизмах, всегда. Тут важно понимать, какие бывают виды простоев. Бывает, что что-то ломается и система выходит из строя, а бывает плановое обслуживание – это тоже простой, когда пользователи не могут пользоваться системой, но в этот момент вы что-то в ней меняете: выкладываете новую версию, исправляете ошибки и так далее. Отказ системы, произошедший из-за выхода из строя оборудования, достаточно просто устранить. Это увеличивает стоимость, потому что надо дублировать все компоненты, но, в принципе, это не очень сложно. А что касается отказов в обслуживании – здесь сложнее, потому что все системы разные, и в некоторых случаях это, действительно, может быть сложно.

Когда вы начинаете раздумывать об отказоустойчивости, не забывайте: как правило, всегда есть внешние зависимости, которые естественным образом ограничивают вашу отказоустойчивость. Это инфраструктура провайдера, канала, всё что угодно. Очень часто любят говорить о так называемых «девятках» – степени надёжности. Многие менеджеры хотят «пять девяток», потому что слышали, как это круто. «Пять девяток» означают, что простой системы составляет не более 5 минут в год. «Четыре девятки» – это уже час в год. «Три девятки» – это 10 часов в год и так далее. Подумайте, какой период простоя допустим именно для вашей системы. В любой системе можно выделить критические компоненты. Это те компоненты, где действительно нужна повышенная отказоустойчивость, например, те самые «пять девяток». Вот эти компоненты, если они у вас есть, стоит выделить и стоит подумать, как повысить их отказоустойчивость. При этом, если это будет касаться лишь отдельного элемента вашей системы, а не всех ее компонентов, вы сэкономите кучу своего времени и денег заказчика, не делая лишнюю работу.

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

Система мониторинга. Это очень важный момент для высоконагруженных проектов. О нём часто забывают совсем или вспоминают в последний момент. Проблема здесь в том, что сам по себе мониторинг, как правило, не является частью проекта разработки, это часть проекта эксплуатации. Когда у вас есть листочек с набором фич от начальника, мониторинга там 100% не будет. Если кто-то считает, что можно сделать высоконагруженную систему, выложить её в продакшен, и она будет как-то работать – то это иллюзия, она очень быстро поломается. Мониторинг – это отдельная большая тема, и по ней можно делать отдельный доклад, поэтому я остановлюсь на нем очень кратко.


• Мониторинг позволяет прогнозировать нагрузку. Если вы видите, что у вас загрузка процессора постепенно повышается изо дня в день и приближается к максимуму – это повод задуматься о том, что нужно добавить машины в пул или как-то оптимизировать работу приложения.

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

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

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

Есть три основных вида мониторинга:


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

• Мониторинг на уровне приложения: ошибки HTTP, исключения, запущенные процессы.

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

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

Это, наверное, самая больная тема. Все что касается фреймворков, языков программирования, технологий, всего чего угодно. Вы приходите к заказчику и говорите, что у вас команда, которая пишет на Java или на PHP, а заказчик говорит, что им требуется только .NET. Что делать? Настаивать на своем и пытаться убедить заказчика, либо бежать от него подальше.

Насколько оправдано жесткое ограничение по технологиям? Есть несколько ситуаций, когда это может иметь смысл. Самая очевидная причина – корпоративный стандарт, когда компания является сертифицированным партнёром Microsoft, что накладывает ограничение на используемые технологии. Другой вариант– когда уже есть готовая система, которая написана на каком-то языке, с использованием какого-то фреймворка (legacy code), и вас просят дописать какой-то модуль. И последний вариант – когда у заказчика есть собственная команда разработчиков, и он собирается в дальнейшем развивать систему своими силами. В этом случае вполне логично с его стороны настаивать на тех технологиях, которые известны его разработчикам.

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

В качестве примера. Однажды нас попросили сравнить PHP и Groovy. Groovy – это такой язык, который основан на JVM, компилируется в байт-код. Про него сложилось устойчивое мнение, что он страшно медленный. «Java-то тормозит, что там говорить про Groovy. То ли дело PHP!» – эту фразу я слышал неоднократно. В результате мы написали простой тест – конкатенация строк в цикле. Было много итераций, от 10 тысяч до миллиона. Как видно – на 10000 итераций PHP работал чуть-чуть быстрее. Начиная с 50000 итераций, уже Groovy работал чуть быстрее. Чем больше итераций было, тем быстрее работал Groovy. Это суммарное время работы теста. Тест был очень простой, просто для того, чтобы показать, что на всякий тест можно написать другой тест, который бы опровергал предыдущий.

Как же выбирать фреймворк? Очень важно смотреть на вашу задачу. Если нужно сделать быстро, например, сделать прототип и посмотреть, как он пойдёт, то писать надо на том, на чём можно быстро сделать прототип, а это, скорее всего, то, чем владеет ваша команда разработчиков. Если у вас есть задача сделать систему управления полётами и потом её поддерживать, то, скорее всего, надо брать то, на чём систему управления полётами уже однажды написали, команда, которую вы выбрали в качестве исполнителей, написала. Надо смотреть на профиль команды. Если команда пишет на Java, то не стоит настаивать, чтобы она писала на PHP.

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

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

Можно ли разделить ответственность, когда систему эксплуатируют одни люди, а отвечают за её работу другие, например, вы? На мой взгляд, нет, потому что человек, который отвечает за систему, должен иметь всю полноту власти, чтобы выполнить свою часть работы. Можно разделить роли, но не обязанности. Например выделить администраторов, которые будут заниматься вопросами «железа», и разработчиков, которые будут отвечать за код. Но они должны быть одной командой в том, что касается работы над системой. Очень важно не упереться в тот самый корпоративный стандарт безопасности, не доводить ситуацию до абсурда. Правильно настроить права доступа, пустить разработчиков туда, куда они просят, или приложить усилия, чтобы предоставить им нужную информацию без ущерба для безопасности компании.

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


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

• Во-вторых, нужно иметь план работ по обновлению, нужно чтобы все участники процесса – и разработчики, и администраторы – понимали свою задачу и последовательность действий, весь процесс должен быть расписан.

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

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

• В-пятых, нужно иметь сценарий тестирования сценария возврата :-), чтобы убедиться, в том, что этот процесс прошел без ошибок.

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

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

Очень важно доверять разработчикам. Этот тезис относится не к данному кейсу, он относится ко всему, о чем я говорил. Если между заказчиком и разработчиками установились доверительные профессиональные отношения, у вас все получится и ваш проект будет жить долго и счастливо 🙂