Менеджмент highload проектов

Highload?

Что вообще такое highload (или высоконагруженные) проекты? Нет какого-то определенного порога, переходя через который проект становится высоконагруженным. Это скорее составное свойство, в которое входят несколько типичных характеристик:

• Много функционала. Это может быть большой набор модулей, как на порталах или соц. сетях. Это также может быть одно специфической направление, но очень глубокое (например, youtube.com или twitter). Второе встречается чаще.
• Постоянный рост. Неуспешные проекты не бывают высоконагруженными. Для того, чтобы стать highload нужен рост, постоянный и уверенный.
• У Вас есть потребность масштабироваться. Это самый важный момент. И это не означает, что у Вас должны быть десятки миллионов просмотров страниц каждый день. Все дело в аппаратном обеспечении и необходимости масштабироваться. Если у Вас стоит один сервер за миллион долларов, который сможет обеспечить Вам десятикратный рост, то до этого момента Ваш проект не высоконагруженный. И наоборот.

Управление высоконагруженным проектом очень не похоже на управление обычным проектом. Почему?

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

Команда

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

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

Глава разработки

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

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

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

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

Минимизируйте и приоритезируйте

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

Типичная работа над новой задачей на highload проекте выглядит так:

1. У нас появляется новая крупная задача
2. Мы детально обсуждаем ее, расставляем приоритеты. Делаем взвешенную оценку важности каждого компонента новой функции для бизнеса и для продукта
3. После этого думаем, что можно выкинуть из задачи — без чего можно начать, попробовать, протестировать эту функцию. При правильном подходе этот процесс позволяет сократить первоначальный объем работ в 2...3 раза.
4. Приступаем к работе над задачей

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

Рефакторинг

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

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

Настройтесь на динамику

Будьте готовы к неожиданностям. В highload проектах их очень много. Это могут быть как технические трудности, возникающие в условиях роста нагрузки, так и стратегические повороты из стороны в сторону. Приготовьтесь к этому сами и приготовьте свою команду. Важно понимать, что Вы не «строите 10 месяцев большой проект», а на протяжении 10 месяцев развиваете проект. Отличие в том, что во втором случае дальнесрочная стратегия имеет только обзорный/поверхностный характер, а детали поведения вырабатываются исходя их показателей в моменте.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU