Управление разработкой высоконагруженных проектов
Я бы, наверное, не хотел, чтобы это было воспринято как некий постулат, которому надо следовать везде, однако просто помните, что такие техники существуют, и ими можно довольно эффективно пользоваться.
ОК. Наверное, давайте начнем.
Как вы знаете, мы будем говорить о разработке высоконагруженных проектов. Сначала хотелось бы определить, что такое высоконагруженный проект, потому что каждый понимает под этим словом что-то свое. Вы не знаете что такое высоконагруженный проект? Это… Больше десяти серверов? Больше одного миллиона хитов в сутки, в час? Огромное количество разработчиков?
Я так понимаю, что в зале есть люди, которые разделяют все три пункта, а еще у вас своих, наверное, есть с два десятка. Так вот, я склоняюсь к тому, что, в принципе, любой Интернет-проект может стать высоконагруженным, и, я вас уверяю, что разработчики Mail.ru, когда только писали почту в далеком каком-то там 90-м году, они понятия не имели, насколько популярным может стать этот продукт. Очень многие продукты в Рунете и в Интернете в целом пишутся без понимания того, что этот продукт будет высоконагруженным. Именно поэтому мы, как разработчики, как люди, которые управляют разработкой, должны понимать, что все, что мы пишем, должно быть рассчитано на то, что проект станет популярным. Иначе, зачем это делать?
Специфика нашей среды заключается в том, что Интернет-среда очень быстро меняется, и те вещи, которые вы хотели реализовать, допустим, полгода назад, на сегодняшний день уже могут стать неактуальными, и от вашего программного кода, от вашей команды, в первую очередь, постоянно требуется очень высокая гибкость, потому что Интернет как индустрия – одна из наиболее быстро меняющихся сред, и именно поэтому вам всегда нужно это учитывать.
И, конечно же, так как мы знаем, что, наверное, из всех вещей Интернет – это среда, где наибольшее количество людей воспользуется вашим продуктом. Такого нет, наверное, нигде – ни в телевидении, ни в машиностроении. Именно поэтому все ваши решения должны быть масштабируемыми, причем беспредельно масштабируемыми.
Итак, давайте обсудим, из чего состоит наша разработка. Во-первых, это команда. Ваша команда определяет технологические решения, которые вы будете использовать в проекте, а вовсе не наоборот. То есть, когда мы выбираем технологию, мы выбираем ту технологию, которую знает наша команда. Что определяют технологии? Технологии определяют, во-первых, стоимость продукта. Поверьте, один и тот же продукт в Интернете можно сделать и за 1000 долларов, и за много десятков тысяч долларов.
И третий кит, на котором все держится, – это менеджмент и планирование, потому что до тех пор, пока вы не научитесь правильно планировать свой ресурс, правильно планировать свои силы, у вас будут проблемы с мотивацией в команде и проблемы с ответственностью. Но, все же, хочется сказать, что самая важная часть процесса разработки – это ваши люди, а вовсе не технологии. Технологии можно создать, можно откуда-то перенять, перенести, а команда – это то, что вы должны формировать, и то, на чем вы, как менеджер проекта, должны делать ваш фокус.
Давайте поговорим о начале. Допустим, с чего мы будем начинать разработку нашего высоконагруженного проекта. Я у себя в компании собрал различные точки зрения – кто-то начинает с техзаданий, кто-то начинает с того, как мы будем проверять, чего мы достигли, кто-то начинает выбирать технологии, а я начинаю с найма людей, если их уже нет. Лучше всего, если людей будете нанимать не только вы, но и те члены команды, которые будут с ними работать. Поэтому выбирайте ваших лучших разработчиков… Понятно, что лучшие ищут лучших, и пусть они ищут себе подобных.
Хочется немножко уделить внимание вопросу найма, потому что я бы хотел еще раз сфокусировать ваше внимание на том что, если у вас есть хорошая команда разработки, у вас все будет хорошо. Если это не так, то вам мало, что поможет. Во-первых, когда вы ищете разработчиков, собеседуйте группой. Если чего-то не заметите вы, заметят ваши коллеги. Также это предполагает, что все члены команды, принимающие конечное решение о том, чтобы взять Васю Петрова, несут впоследствии ответственность за этого Васю Петрова, а не только вы, как менеджер, несете ответственность за то, что взяли такого неуча.
Начинайте собеседование с написания кода, потому что вам это потом сэкономит огромное количество времени. Не так важно, где Вася учился и когда он женился, как то, насколько хорошо он программирует, ведь вы берете его программистом. Следующая вещь, о которой я хочу сказать. Есть такая очень распространенная ошибка, особенно часто она встречается в тех компаниях, где разработка не является основным направлением деятельности, от человека просят всего: чтобы он был и программистом, и верстальщиком, и DBA, и немножечко админом. Вот я, сколько таких универсалов встречал, они одинаково плохи во всем. Лучше найти хорошего специалиста в узкой области, чем человека, который будет полным нулем во всех областях.
Следующий момент, это то, что во всем процессе разработки единственное место, на которое нужно тратить максимум времени, – это собеседование. После того, как HR привел к вам человека, после того, как ваш HR отсеял тех людей, которые совершенно не подходят, потратьте времени на кандидата столько, сколько нужно – это окупится в десятки раз. Ну и последнее, еще раз хотелось бы вспомнить, что выбирать людей должны лучшие. Отличники нанимают отличников, а хорошисты – троечников.
Есть такое выражение, оно, к сожалению, не мое, его придумал Колларенс, человек, очень известный в тусовке PHP-разработчиков, которое звучит так – «все разработчики хотят разрабатывать, но не все хотят разрабатывать для вас». Я, в принципе, с ним согласен и сейчас я хочу с вами поговорить о том, что нужно сделать, чтобы разработчик хотел разрабатывать для вас, в ваших проектах, в вашей компании.
Вы знаете, все разработчики очень любят чувство собственности кода, чувство уважения и признания их заслуг. Объясню, почему я акцентирую на этом особое внимание. Потому что, вот существует такая должность, как менеджер по продажам. Там очень четкая характеристика, много принес денег – большой молодец, уважуха, почетная грамота, поцелуй от генерального директора. Есть менеджер проекта – это человек, который делает проект целиком. Соответственно, проект запустился хороший, вовремя, в срок – молодец, плохой, не вовремя, не в срок, не работает – плохо. А разработчик – такая фигура, которую очень тяжело оценить. Конкретный разработчик хорошо поработал или плохо поработал? И именно поэтому, как правило, разработчиков очень редко хвалят. Хвалите своих разработчиков, и это очень хорошая мотивация. Для многих разработчиков это важнее, чем деньги.
Следующий пункт, на котором я хочу остановиться, – это чувство собственности своего куска программного кода. Эта проблема актуальна в больших компаниях и заключается в том, что, когда у вас есть большая команда разработки, часто код мигрирует от одной команды к другой, от Васи к Пете. В итоге уже никто не знает, кто начал делать, кто закончил, кто придумал вот эту фигню, которая мешает жить всей компании, и так далее. Поэтому старайтесь сегментировать разработку таким образом, чтобы было один-два конкретных программиста, которые отвечают за каждую конкретную процедуру. Чтобы в случае каких-либо проблем в проекте, если вы нашли эту проблему в коде, что довольно редко бывает, вы знали, к кому подойти и сказать: «Ну что же ты сделал?». Это должна быть конкретная фамилия. Это не должен быть начальник отдела разработки, это не должен быть весь отдел разработки, это должен быть конкретный человек. И все должны знать имя и фамилию этого конкретного человека, который отвечает за этот кусок кода. Это нам помогает достигать неплохого качества.
Пару слов о том, кто должен быть руководителем вашей команды разработки. Я хочу сказать, что это должен быть самый уважаемый член команды. Что это значит? Это значит, что авторитет этого человека среди разработчиков должен быть настолько велик, чтобы это экономило время на объяснение каких-то вещей. То есть авторитет не в том смысле, что его назначил такой высокий директор, что нужно падать ниц, а в том смысле, что этот человек настолько много знает, что это лучший разработчик в нашей команде. Это позволяет экономить время в спорах, это позволяет решать большое количество менеджерских задач.
Следующая вещь, о которой я хочу поговорить, это прозрачность принятия решений. Она позволяет нам формировать команду особым образом. Что это значит? Все члены вашей команды должны понимать в любом вопросе, почему принято такое решение. Что это значит? Это значит, что я предложил архитектуру «A», кто-то предложил архитектуру «B», и я, как разработчик, должен четко понять, почему мы решили делать не то, что я предложил. Также я должен понимать, почему мы выбираем такие методики тестирования. То есть на все вопросы «почему» у меня, как у разработчика, должны быть четкие и прозрачные ответы, которые снимут довольно большое количество напряжения в команде. Вы сами знаете о том, что многие относятся к процессу разработки, как к некоему творчеству, и поэтому, когда принимается решение не в вашу пользу, это довольно тяжело пережить, и поэтому прозрачность принятия решений очень полезна. Каким образом достигается прозрачность – очень простым. Очень здорово, если все члены команды находятся в одном помещении, если все слушают разговоры друг друга, если все принимают участие в обсуждении. Я вообще противник совещания как такового, то есть когда все встали, поднялись, пошли в комнату переговоров, посидели там 6 часов, попили чай, разошлись. Нет, совещание должно происходить непосредственно на рабочем месте. И, если вам есть, что добавить, вы можете встрять в разговоре, если нет, то просто продолжаете программировать.
Последняя вещь – это открытые коммуникации. Это то, что вы, как разработчик, или вы, как менеджер, должны создать такую систему оповещений, такую систему обсуждений, когда все члены команды понимают, что делает их коллега. Самое ужасное, это когда сидят два разработчика рядом, и одного спрашивают: «Вася, а чем занимается Петя?». А он: «Я не знаю». Вот это все плохо, потому что они никогда не поделятся опытом, они никогда не обменяются куском своего кода, это значит, что Петя никогда не расскажет Васе о том, что он только что наступил уже на эти грабли, которые Вася только программирует.
Пару слов о ролях в IT-команде. Это те роли, которые, как я считаю, обязательно должны быть в каждой команде. Первая роль – это IT-менеджер. IT-менеджер в нашем процессе разработки – это некий играющий тренер, это не руководитель, не менеджер продукта, это человек, который всегда подходит к разработчику, который всегда находится рядом с разработчиком, который знает, кто что делает, знает, почему он сейчас это делает, и знает, когда это будет готово. То есть IT-менеджер – это отец команды.
Следующая позиция – это архитектор. Задача этого человека – привносить в разработку какие-то новые идеи, потому что ни для кого не секрет, что часто глаз замыливается. Когда мы 10 лет делаем один и тот же продукт, часто очень тяжело привнести туда что-то новое, и задача этого человека – быть практической реализацией R&D. Кстати, а вот я так знаю, у кого-то есть R&D в компании? Что у вас значит R&D? Research and development? R&D – это results and development. То есть ваше подразделение R&D должно приносить результат – конкретные привнесенные вещи, которые вы реализуете в вашем проекте.
Нужно позиционировать разработчика таким образом, чтобы он был человеком, который отвечает за что-то. Если ваш разработчик ни за что не отвечает, то у вас проблемы с менеджментом, потому что его очень тяжело мотивировать. Разработчик – это полностью ответственный за какой-то результат человек.
Дальше. Администратор или ответственный за продакшн, у кого как называется, – этот человек необходим для того, чтобы ваша команда разработчиков узнавала в первую очередь о том, что происходит после того, как они закончили программировать свой продукт. После того, как это попадает на продакшн, администратор, человек, ответственный за продакшн, – это единственный человек, который может донести до разработчиков информацию о том, что они сделали. Я не рассматриваю тот вариант, когда у разработчика нет доступа на живые сервера, – это идеологически неправильно, это приведет к большим проблемам, поэтому у администратора функция не только администрировать, но и быть обратной связью. «Ребята, вы мне принесли с этими апдейтом большие проблемы», – если он это не скажет, разработчики ваши продолжат разрабатывать таким образом, что он рано или поздно повесится.
Последняя роль в команде – тестеры. Что такое тестеры в Интернет-проекте, это тема для отдельного доклада. Мы решили, что тестеры – это группа пользователей, которые имеют какой-то доступ к разработчику. Это люди, которые могут воспользоваться бета-версией проекта, которые входят в какое-то отдельное комьюнити и которые конкретному разработчику могу написать «Ты вчера мне написал чат, я сегодня его использовал – это, это и это не работает». Причем, самое смешное, нам так в Интернете повезло, что людям это еще и нравится. Я думаю, что если взять и начать брать за это плату, они будут платить. Надо пользоваться этим.
Я, естественно, не буду говорить ни о каких конкретных технологиях, я лишь хочу сказать о том, какой чек-лист должен соблюсти при ее выборе. Технология для вас будет хороша… Я именно сказал «для вас», потому что для соседних компаний она может быть плоха. Если эта технология знакома вашей команде. Если вы знаете конкретных людей, которых можно нанять, которые это уже делали, которые придут и принесут вам эту технологию. Если эта технология беспредельно масштабируема горизонтальным способом. Это значит, что вы можете в любой момент поставить столько серверов, сколько вам надо. Если вам нужно покупать более, более и более мощный один сервер, эту технологию надо выбросить и с самого начала никогда не использовать, потому что, что бы ни говорили о том, что сервер – это дешево, я вас уверяю, есть компании, где сервера очень дороги, а нагрузки очень велики.
Принимайте решения на основе собственного опыта, а не на основе советов своих коллег, потому что у ваших коллег может быть другая команда, другая компания, и их опыт перенести к вам будет довольно тяжело. Отдельно хочу сказать о тестах, которые можно легко найти в Интернете. Любой тест, любой синтетический тест я могу развернуть на 180 градусов и показать совершенно другие результаты. В синтетическом тестировании очень тяжело показать то, что происходит на самом деле, поэтому решения о том, выбрать MySQL или Oracle, должны принимать вы самостоятельно, а не журнал за вас. Ну, и про сервера я уже говорил, что масштабируемся только количеством, а не качеством этого сервера.
Перед тем, как начать нашу разработку, мы должны немножечко попроектировать. Здесь вам показан чек-лист процесса проектирования, который применяю я. У нас в процессе проектирования принимает участие вся команда – от продуктового проектного менеджера, который, в принципе, может быть довольно далеким человеком от IT, до бета-тестера, коли такие существуют в проекте, – потому что таким образом вся команда может учесть свои интересы в этом проекте.
Итак, на какие вопросы мы должны ответить для себя:
- Как мы будем масштабировать нагрузку, если она будет?
- Как мы можем юзать что-то из уже того, что у нас уже есть? Как правило, в компаниях уже есть какие-то наработки, которые, если применить к ним фантазию, можно использовать в текущем продукте.
- Как мы применим то, что мы запрограммируем сейчас, в наших будущих продуктах? Часто бывает достаточно дописать совсем немного кода, чтобы проект стал портируемым и юзабельным в наших последующих продуктах.
- Должны выбрать ответственного. Не обязательно это должен быть тим-лидер. Для вашей конкретной разработки это может быть любой программист, который лучше всего в этом разбирается. Конечно, нужно понимать, что за любую разработку должен отвечать тот человек, который в этом лучше всего понимает.
- И последний очень важный момент, о котором мы часто забываем. Когда мы это сделаем?
Это нужно даже не столько для того, чтобы ответить клиенту, ответить вашему внутреннему заказчику, когда это будет готово. Это нужно вам, как IT-менеджеру, для себя, чтобы проверить, насколько хорошо вы знаете технологии, насколько хорошо вы угадываете дэдлайн, насколько хорошо вы понимаете, когда это будет. Это очень интересная игра. Чуть-чуть попозже о ней расскажу.
Итак, для нашей разработки какой инструментарий нам нужен?
В первую очередь нам нужен таск-трекер. В таск-трекере мы увидим, собственно говоря, кто и что делает, кто и что будет делать. Следующая вещь – это система контроля версий. Вы все знаете, что это такое, но я хочу сказать, что в нашей, так сказать, парадигме система контроля версий – это не только система версификации, но и обязательный этап системы развертывания.
Вот такая штука называется радар. Вообще радаром может быть все, что угодно. Радар – это может быть whiteboard. Радар – это может быть стена, на которую мы прилепили бумажки с текстом. Радар – это может быть записная книжка, лежащая у всех на одном столе. Смысл радара в том, чтобы любой разработчик, любой член команды мог, подняв глаза от монитора, увидеть, есть ли та задача, которой он занимается, на этом радаре или нет. Потому что в больших командах в длительных проектах очень часто сложно определить, насколько нужно то, что ты делаешь, настолько важно это в данный момент. Поэтому радар – это инструмент, куда руководитель команды может поместить задачу и, соответственно, разработчик поднял глаза и увидел – о, я занимаюсь важной вещью! Или там поднял глаза, и его задачи нет, он подходит к руководителю и говорит: «Слушай, я тут фигню какую-то делаю». И тогда задача меняется, и это помогает заниматься всем людям в команде важными вещами, потому что у меня бывали случаи, когда половина команды занимается важными, но не очень, вещами, и в итоге половина времени пастится в никуда.
Следующая вещь – список идей. Это может быть некий документ, может быть все, что угодно. Его идея какова? Особенно в длительных проектах часто бывает, что кому-то приходят идеи, которые невозможно реализовать сейчас, или в них нет потребности, нет времени, желания, еще чего-то. Для этого эта идея помещается в этот idea-list, и всегда к ней можно вернуться, потому что человеческая память такая штука – кто-то что-то забывает, кто-то потом это тяжело вспоминает. А так всегда, когда у нас есть свободные пять минут, открываете список идей и смотрите, что клевого мы уже придумали, но еще не сделали. Вот, очень полезная вещь, очень рекомендую!
Должна быть какая-то документация. Тоже очень такой дискуссионный вопрос – в каком объеме должна быть документация на проекте. Мой ответ на этот вопрос – документация должна быть в том объеме, который позволяет вашему разработчику, вновь нанятому, вникнуть и начать эффективно программировать. Соответственно, для каждой команды этот ответ будет разным. Где работают умные ребята – документации достаточно всего чуть-чуть. Если у вас команда не очень хороших разработчиков, вам тома понадобятся, поэтому, опять же возвращаясь к вопросу найма, нанимайте хороших разработчиков – это очень сильно дешево.
Я, в принципе, пропагандирую средство учета времен, любое. Оно нужно не для того, чтобы контролировать разработчика, что он там не пьет кофе или не ходит в туалет слишком много времени. Оно нужно IT-менеджеру для того, чтобы он реально понимал, насколько правильно он угадал, сколько времени займет та или иная задача и, в случае проблем, которые во всех проектах бывают, эта же штука поможет ему понять, что пошло не так, в какой момент мы сдвинулись с графика, в какой момент отвлеклись на ту задачу, которой не было в плане.
Возвращаясь к техзаданию, знаете, я не знаю, нужно оно или нет, на самом деле. Но базово вот те принципы, по которым можно решить, нужно ли техзадание или нет.
Да, если проект больше месяца, если работает много команд, если есть удаленные команды, если есть аутсорс-разработчики – техзадание точно нужно.
Нет, если проект короткий, если такой проект мы уже делали, что часто бывает, или если команда помещается за одним столом – техзадание не нужно, это все можно обсудить.
Лучшее техзадание, по моему опыту, – это работающий макет. Это если кто-то что-то заранее покажет хотя бы на уровне html-верстки.
Теперь самый важный слайд. Как правильно структурировать процесс разработки. Когда у вас уже есть команда, когда у вас уже есть какое-то техническое задание, что вам нужно сделать. Должны сесть вы, как IT-менеджер, и менеджер продукта, и расписать последовательность реализации тех или иных этапов. Причем это не обязательно должен быть некий таймлайн. Это просто может быть некая последовательность того, что мы делаем сначала, что мы делаем потом.
После того, как вы приходите к консенсусу, вы должны проверить следующие вещи. Первое, вы раздробили процесс разработки на минимальные кванты. Что это значит? Это значит, желательно не больше недели, потому что неделя – это и так большой срок. В идеале – еще короче. Результатом каждой разработки является развертывание на продакшн-сервер. То есть максимальный цикл разработки – это неделя. Будет очень здорово, если в результате вашей разработки на продакшн-сервере получается что-то, что можно увидеть. То есть, какая визуализация существует, и конкретный разработчик может сказать: «Вот смотри, эту кнопочку сделал я на этой неделе».
Когда вы формируете список задач, которые будут выполнять ваши разработчики, позволяйте им выбирать задачи, потому что это хорошо, когда я делаю то, что мне интересно – это меня мотивирует. Но у этого метода есть одна проблема, которую я называю расслоением команды. Это значит, что любая команда в итоге разделяется на тех людей, которые делают супер интересные мегасупергиперфичи, и тех, которые подверстывают, подфиксивают, в общем, выполняют совершенно проклятую работу. Вот надо с этим бороться, надо делать так, чтобы всем доставались и интересные, и неинтересные задачи по чуть-чуть. Это людей мотивирует.
Не начинайте обсуждать разработку, пока есть какие-то сложности, нерешенные ответы, потому что лучше вы сейчас со всей командой обсудите этот вопрос, чем конкретный разработчик примет для себя это решение, даже не спросив вас.
Итак, теперь как выглядит наша разработка каждый день? Из таймлайна мы выбираем какую-то конкретную задачу или список задач на эту неделю. Каждый день мы 15 минут, максимум 20 минут, проводим встречу всех участников проекта, это делается в начале дня, чтобы люди поделились друг с другом, кто что сделал, кто что собирается делать, какие проблемы есть – 15-20 минут максимум. В качестве штуки, которая заставит людей говорить кратко, можно делать standup-session – стулья убрать. Как правило, способствует краткости.
После того, как цикл разработки прошел, наша неделя прошла, если у вас это короче – это еще лучше, мы делаем развертывание и финальное обсуждение того, что мы запрограммировали за эту неделю. Обязательно надо обсудить, что получилось хорошо, потому что от этого у вас, как у IT-менеджера, появляется понимание сильных мест своей команды, это вам поможет понимать, что эти вещи лучше возьму делать я, а эти вещи пусть делает кто-то еще – это не моя сильная сторона.
Конечно же, обсуждаем, что получилось плохо, и на эти вопросы нужно обязательно ответить, почему. Придерживаясь такого еженедельного спринта, можно без наличия подробного техзадания, без наличия хороших формализаций достигнуть довольно эффективной, быстрой и дешевой разработки.
Я даже не знаю, стоит ли мне говорить об этом слайде, потому что столько копий сломано. Нужны ли тестеры? Как нужно тестировать? Просто кратко расскажу свое мнение. Сразу говорю, что спорить не буду, потому что я знаю двести мнений, наверное, сколько людей сидит, столько мнений существует на тему тестирования. Для себя мы приняли решение, что лучше всего, если мы находим группу пользователей, которые готовы протестировать наш финальный продукт, какое-то комьюнити. Если вы, разрабатывая свой продукт, не можете найти группу пользователей, которой он будет интересен, подумайте, зачем вы его разрабатываете, кто им пользоваться будет. А те вещи, которые, к сожалению, нельзя переложить на плечи пользователей, распределяются по нашему отделу разработчиков: нагрузочное тестирование – за разработчиком, системное тестирование – за проектным менеджером, так как он знает, что он хотел видеть, функциональное тестирование – за автоматизированным ПО.
Хочется поговорить о тех «если», с которыми встречаются все. Первое «если», которое регулярно происходит, это когда я, как IT-менеджер, не угадал. На старуху тоже бывает проруха, поэтому, что я делаю в этом случае? Во-первых, я обязательно обсуждаю с командой причину сдвига сроков, потому что у каждого может быть свое видение, и люди могут мне рассказать о тех проблемах, о которых, я в принципе, не догадывался.
Второе, что обязательно нужно сделать, – нужно назначить и зафиксировать новый дэдлайн, потому что если мы будем двигаться в процессе «ну сейчас доделаем, ну еще чуть-чуть», я видел разработки, которые в режиме «ну еще щас», длились, наверное, восемь месяцев. Где-то должен быть новый конкретный дэдлайн.
И последняя вещь, о которой я хочу поговорить, – это об овертайм-работе. Знаете, за десять лет управления разработками я для себя открыл потрясающую вещь, в принципе, это не только разработки касается, это всего касается. Человек может работать строго определенное количество часов. Для каждого человека это число разное, но самое поразительное, что находиться на работе он может намного больше, чем это количество часов. Поэтому всегда, когда вы просите разработчика «ну, Вася, ну посиди еще чуть-чуть», помните о том, что число эффективных рабочих часов у каждого конкретного Васи ограничено, и, сколько бы вы ему премий не пообещали, он все равно эффективно работать не будет больше.
Следующее «если», которое иногда нас всех постигает, – это изменившееся ТЗ. Тут, конечно, команда обычно благодарит проектного менеджера, но, тем не менее, эта проблема существует, и для того, чтобы в вашей команде не возникало напряженностей, обязательно нужно обсудить с ней, почему это произошло. Особенно в Интернет-проектах это бывает часто, поскольку, пока вы писали одну штуку, конкурент уже запустил другую, и нужно срочно что-то где-то быстро лучше, чем у конкурента. Поэтому у всей команды должно быть четкое видение, почему мы бросили писать то и начали писать это. Это первое.
Второе – попытайтесь сократить срок, использовав что-то из уже написанного. Как правило, то, что просят менеджеры проекта, редко когда на 180 градусов отличается от того, что вы уже писали. Возможно, что, применив смекалку, это можно чуть-чуть доделать, чуть-чуть переделать, где-то договориться с менеджером, и вот у вас не полностью новый продукт, а чуть-чуть переделанный ваш старый. Если у вас есть возможность закончить вашу старую разработку, всегда лучше это сделать, потому что есть такое понятие, как «стоимость переключения». Это стоимость обсуждений, стоимость постановки техзадания, стоимость вашего спора с проектным менеджером, стоимость обсуждения конкретной архитектуры с программистом, и она очень велика. Поэтому, если есть шанс что-то доделать, это надо доделать.
И не попадайтесь в самую главную ловушку IT-менеджера, когда к вам приходят люди и говорят: «Ну, тут же пять минут. Вот тут вот чуть-чуть». Тут, там пять минут, за день сто задач, и в итоге половина вашей команды занимается совершенно другими задачами, которые не имеют отношения к вашему основному проекту. Каждый раз, когда к вам пришла какая-то внешняя задача, которой не было в плане, отразите ее в вашем временном плане. Как правило, когда IT-менеджеры это делают, менеджер проекта говорит: «Боже мой, ну зачем ты меняешь план? Это же всего пять минут!» Я ему на это отвечаю: «Я же и меняю всего на пять минут. Чего ты нервничаешь?» Поэтому всегда нужно отражать даже самые мельчайшие изменения в плане – это важно, это вам потом поможет понять, что произошло, почему мы не угадали сроки.
Хочется еще поговорить о развертывании продакшн. Так как мы не имеем специально выделенного отдела тестирования, для нас развертывание продакшн воспринимается еще и как этап тестирования. Все развертывание продакшн должно быть полностью автоматизировано. Это значит, что развертывание должно происходить по одной кнопке. Системный администратор или ответственный за продакшн нажимает на одну кнопку, и вперед-поехали. Это позволяет нам раскладывать на продакшн сервера наш софт одним и тем же способом, а не 25-ю разными по количеству членов команды эксплуатации.
Следующий момент – боевое и тестовое развертывание. Боевое – это когда мы раскладываем на живые сервера, тестовые – когда раскладываем на тестовые, должно выполняться одним и тем же скриптом или одной и той же тулзой, которая у вас занимается развертыванием. Это позволит нам иметь в репозитории такой код и такие утилиты, которые позволяют добиваться одинакового результата на тестовом сервере, где разработчик полностью хозяин и может сделать все, что угодно, и на продакшн-сервере. Соответственно, когда разработчик сам на свой тестовый сервер раскатывает с помощью этих утилит и ничего не собирается, это сэкономит время админу, который попробует собрать это на живых серверах, у него не соберется, он пойдет к разработчику, скажет: «Вот, у тебя ничего не работает». Поэтому, если у вас одни утилиты и там, и здесь, это просто сокращает время. Конечно же, еще раз хочу обратить внимание, что развертывание – это дело группы эксплуатации, группы системных администраторов, программистов эксплуатации. Главное, что это не те же люди, которые занимаются написанием кода, потому что остановить себя, когда ты имеешь root на сервере, что-то подправить на живом невозможно. Не подвергайте своих разработчиков такому соблазну. Это кончается всегда плохо.
И еще один очень важный момент, который вам позволит, так сказать, уменьшить количество проблем. Это развертывание исключительно из системы контроля версий. Неважно, что это будет: CVS, SVN, еще что-то – неважно. Важно, чтобы код не поехал на живые сервера с тестового сервера, от разработчика, еще откуда-то. У вас есть система контроля версий, вот оттуда выкладываем. Любой тестовый сервер – это сервер, который должен быть сожжен, причем безболезненно для процесса разработки. Такой подход позволит вам иметь актуальную копию софта в вашем репозитории – раз, возможность воспроизвести то, что находится на живом сервере, на втором таком же, – два. Потому что переносить отдельные библиотеки, отдельный софт или отдельные какие-то шаблоны и еще какие-то вещи с тестового сервера очень тяжело.
Ваши вопросы?
- Дмитрий Гулев, разработчик. Владимир, спасибо вам за интересный доклад. У меня к вам вопрос по поводу процесса разработки. У вас было сказано… Мне кажется некоторое противоречие, просто. С одной стороны говорится, что у нас разработчики любят, когда код кому-то принадлежит, когда есть некоторая собственность, когда кто-то отвечает за конкретный код. Вот я написал код – я за него ответственный, да? Но это, с одной стороны, противоречит кросс-функциональности, которая в Agile пропагандируется. Понятно, что кросс-функциональность – это, конечно, идиллия. С другой стороны, это противоречит тому, что дальше в слайде написано – «Боритесь с расслоением команды». Вот это как вы можете прокомментировать?
- Владимир Габриелян. Давайте я вам немножко объясню. Эта презентация – это видение, это мой подход к Agile. Я просто десять лет использую, тогда этого слова еще не было. Я считаю, что лучше иметь одного ответственного или двух, потому что с одним человеком может что-то случиться, за продукт, чем иметь такую массу разработчиков, которые универсальны на все руки. Что касается, как выбрать между тем, что нам будет лучше – сделать ли нам четкую ответственность или сделать нам командную работу… Для меня ответ заключается в том, что лучше всего, когда у вас есть группа разработчиков – один, два, три, – которые занимаются определенной частью продукта, и просто следующая интересная задача достается другой группе. Когда для каждой группы существуют и сложные задачи, и простые. Нужно бороться с расслоением таким образом.
- Дмитрий Гулев, разработчик. Понятно. И второй маленький вопрос. Вы говорили про средства учета времени. А какие вы используете?
- Владимир Габриелян. Мы используем свое собственное.
- Вопрос из зала. У меня короткий вопрос по поводу того, вот работают разработчики, хотя получать удовольствие от работы, это мы им можем предоставить, они еще хотят получать зарплату, ну и наша задача – заметить, что кто-то хорошо работает, кто-то работает плохо, кому-то дать премию, кого-то похвалить. Как это решается?
- Владимир Габриелян. Смотрите. Вот тот процесс разработки, о котором я говорю, подразумевает очень короткие этапы. В конце каждого этапа существуют встречи, где люди обсуждают, что получилось, что не получилось. Соответственно, так как встреча групповая, зачастую очень хорошо видно, почему возникла проблема, и, по сути, вся команда решает, кто молодец, а у кого возникла проблема. Это очень хорошо видно. Просто достаточно присутствовать на этой встрече. Увидеть, кто, как себя ведет, кто, что сделал в этом проекте.
- Вопрос из зала. Еще один вопрос. У вас в схеме на неделю – неделя кончается выкладкой. А где там тестирование? Какое у вас соотношение тестовых разработчиков?
- Владимир Габриелян. Еще раз. Я показывал то, что непосредственно человека, который носит должность тестера, у меня нет вообще ни одного.
- Вопрос из зала (уточнение). Функциональные тесты кто пишет, а также автоматические и системные?
- Владимир Габриелян. Программисты.
- Вопрос из зала (уточнение). Это все в рамках работы команды?
- Владимир Габриелян. Да.
- Вопрос из зала (продолжение). А отвечает кто?
- Владимир Габриелян. Вот ты разрабатываешь определенную функцию, ты для нее написал тест, ты отвечаешь за результат – даже свалить не на кого.
- Вопрос из зала. Выкатываются ли баг-фиксы в середине недели?
- Владимир Габриелян. Смотри. То, что я сказал про длину цикла в неделю – это максимальная длина, а в рамках этой недели может быть, я с Петей закончу работу за полдня, и, соответственно, тут же происходит тестирование и релиз. Кто-то заканчивает через неделю, соответственно у них – через неделю тестирование и релиз. Неделя – это не тот момент, когда все закончили и все выходят в продакшн, а максимальный срок разработки, который позволяет очень четко контролировать, кто, что делает.
ОК, ну, если у кого-то есть вопросы, можно ко мне подойти, я никуда не убегаю – обсудим.
