А теперь к делу, точнее, к нескольким особенно запомнившимся докладам.

Юрий Шиляев с выступлением «Иди и управляй! Или 3 ритма проектного управления» долго и тщательно демонстрировал нам свой успех и незаменимость в роли «самого читающего тренера» в его компании. Что касается пользы для присутствовавших в зале, она была, на мой взгляд, не так очевидна. Забавно, конечно, было в очередной раз услышать радикальные идеи о том, что лучше просить прощение, чем разрешение. Что правила придумали идиоты, которые не умеют принимать решения, и потому, как поётся в популярной песне, «пусть лучше мир прогнётся под нас». Но я человек правил, и могу воспринимать такие заявления только как проявления самоуправства и полного игнорирования интересов окружающих. Да, я готова согласиться с тем, что победителей не судят, но только в тех компаниях, где на самом деле важен результат и где способны его оценить без оглядки на нарушение процессов и правил. Много ли таких вы знаете? Впрочем, Юрий высказал и несколько весьма полезных мыслей. Что внедрение любого нового процесса в команде – это вовлечение в «здесь так принято». Что лень менеджера непременно аукнется ленью и равнодушием остальных участников работы над проектом. Также очень интересным лично для меня показался набор вопросов, на которые нужно получить ответ при собеседовании потенциального сотрудника: сможет ли (… делать то, что требуется по его профессиональной роли), будет ли (…делать именно то, что нужно, и именно так), подойдёт ли (… в команду).

Обычно я с большим удовольствием хожу на выступления практиков, но иногда теоретический доклад способен произвести не менее сильное и, что важнее, вдохновляющее, впечатление. Рассказ Михаила Кумскова о принципах Деминга – один из прекрасных тому примеров. Неторопливое описание всех 14 принципов звучало как перечисление кораблей в исполнении Гомера, так же масштабно, детально и при этом захватывающе. Михаил показал любопытную статистику о причинах провалов в проектах (чаще всего – из-за некачественной работы с требованиями), а также перечислил факторы, в значительной степени влияющих на успех. Так, 18% отводилось поддержке со стороны высшего руководства, и на него же возлагалась ответственность за качество решения в целом.

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

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

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

Конференция для меня закончилась феерическим докладом «Humanized Software Development» Стаса Фомина. Сравнение программистов с ведомыми на бойню коровами, которые ждут свою Темпл Грандин, мотивация производительности сладостями, краткий экскурс в область страхов разработчиков и их «антивахтёрность» – всё это мгновенно растащили на цитаты в твиттере, и не зря.

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

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

Уже традиционно для моих выступлений, я начала с описания непрерывного потока входящих задач, его количественных характеристик (много, много) и качественных особенностей (пересмотр приоритетов, изменение требований). Мне было важно показать, в каких условиях возникает потребность в потоковой разработке, чтобы затем сосредоточиться на том, как же в таких условиях нужно работать. Однако прозвучавший вопрос показал, что, возможно, я слишком сильно сгустила краски. Звучал он примерно так: почему руководство не решает проблему с таким непомерным количеством задач? О наивности веры в барина, который приедет и рассудит, ещё Некрасов писал, но вот нет же, до сих пор актуально. Я ответила просто: проблема не в количестве задач, ведь каждая кому-то и для чего-то нужна; проблема в нашей (возможной) неспособности этот поток требований адекватно обрабатывать. Однако позже я задумалась, в какой момент я бы ожидала вмешательства или помощи от руководства? Если оставить в стороне очевидные роли заказчика и контролёра, остаётся, мне кажется, только позиция реферера, судьи, к которому можно обратиться при возникновении конфликта интересов между проектами или командами.

Иногда руководитель берёт на себя обязанности и другого рода, скажем, координаторство или проработку архитектуры системы. Одна это скорее совместительство, не так ли?

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

Но это всё детали… Надеюсь, я дала студентам информацию к размышлению, как и они мне – своими вопросами.

Что вызывает плохие предчувствия, так это появление виртуального второго этапа, копилки всего, что не успели или не смогли. Причины всегда есть, и часто они очень хорошо обоснованы. Сделаем сразу после запуска, чтобы не срывать обещанные сроки. Сделаем после завершения рефакторинга, потому что тогда решение будет проще, быстрее, надёжнее, идеологически правильнее. Сделаем позже, когда сформируем устраивающее всех техническое решение. Говорила ли я сама что-то подобное? Да, и не раз. И всегда – исключительно в интересах проекта. For the greater good, как говорил один мудрый волшебник.

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

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

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

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

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

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

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

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

Байрам Аннаков начал рассказ об «Управлении распределенной командой разработчиков» с того, что мне бы хотелось сделать самой, – отказался от использования микрофона, чтобы иметь возможность свободно жестикулировать обеими руками. Завидую смелости.

Вопреки заявленной теме, рассказ был посвящён принципам, применимым как для распределённой, так и обычной команды. Перечислю только некоторые из них.

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

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

Предлагалось также внедрить армейский принцип «получил приказ – повтори его». Для чего? Чтобы убедиться, что разработчик понял задачу полностью и верно. Необходимость вести записи во время любых обсуждений обосновывалась тем, что только так человек успеет подумать (и задуматься) над обсуждаемым вопросом.

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

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

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

Формулировка темы доклада Германа Клименко «Секреты оптимизации и найма программистов» показалась мне очень-очень странной. Оптимизация – чего? С одной стороны – чего? Грибааааа. Оказалось – речь о поисковой оптимизации сайтов. А при чём здесь программисты, спросите вы вслед за мной. Оказывается, с разработчиками, как с заказчиками SEO, нужно быть очень терпеливым.

А дальше последовал поток утверждений, после каждого мне хотелось то ли демонстративно выйти, то ли горько рассмеяться, то ли попросить микрофон и задать единственный вопрос: «вы это всё серьёзно?». Поделюсь особенно яркими примерами:

Программистов надо заставлять взаимодействовать друг с другом. Сами, по доброй воле, они не будут делать этого никогда.

Не нужно требовать документирование кода, бесполезно. Всё равно с передачей разработки другой команде весь код будет переписан заново. Ну да, если вы можете себе это позволить… (Я, как раз, очень люблю порассуждать об осмысленности документирования.)

Программисты всегда опаздывают и это нормально. С нажимом так. Если разработчик приходит к 9 утра и уходит в 18, это не настоящий программист, это какой-то другой подвид, несуществующий. (Ну да, ну да…)

Что хвалить не обязательно, и достаточно, как в армии, не наказывать за допущенные ошибки.

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

Следующий доклад, Дмитрия Башакина «Жизненный цикл команды: академический термин или практический инструмент менеджера?», показался мне по сравнению с предыдущим выступлением образцом корректности и вдумчивого подхода к произносимому. Хотя мне показалось, что тема, процесс командообразования, была подана немного слишком академично, возможно, я просто не являюсь целевой аудиторией подобных рассказов, так как намного легче воспринимаю отсылки к практике и опыту, чем к теории.

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

В целом, впечатления от конференции остались самые приятные, за что большое спасибо организаторам.

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

Даже метафоры как на подбор были немного злые. Так, тезис о вынужденной смене команды был проиллюстрирован образом замерзающий покусанной насекомыми черепахи, скинувшей старый панцирь и ещё не нарастившей новый.

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

Рассказ Дэвида Хассмана (David Hussman) «Products and People Over Process and Dogma» зазвучал в совершенно иной тональности. Гуру Agile-движения осмелился предлагать в конкретных случаях брать от теорий (Scrum, LEAN и т.д.) только те инструменты и процессы, которые на самом деле могут решить имеющиеся проблемы проекта или компании. Поскольку мне кажется, что в своей работе я затрагиваю некоторые принципы Agile, такая мягкая позиция мне очень близка.

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

Мне лично показался очень интересным пример фирмы, которая выпускала по 50 релизов в день, и от каждого мгновенно получала пользовательский feedback. Число выкладок, конечно, фантастическое, но интересно, что релиз, который для меня является практически последним этапом работы по поставленной задаче, для кого-то является инструментом для получения промежуточных результатов.

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

Следующее выступление, «Leaders Performance», в исполнении Пола Борна (Paul Bourne), неприятно удивило. На фоне английского английского, ласкавшего слух после американского английского Дэвида, отсутствие британской сдержанности по меньшей мере смутило. Презентация, театральная донельзя, с шумом и треском, с потоком риторических вопросов к залу, оглушала, но если отключить чувства и оставить, прошу прощения, интеллект, осознаёшь, что в результате пять-десять минут уходило на многократное повторение одной (и довольно простой) мысли, ещё десять – на разжёвывание второй мысли, и следующие пятнадцать – на повторение … первой. На любое воздействие будет реакция. Нужно выстраивать общение. Человек важнее идеи. Весь мир театр, быть или не быть и прочие цитаты из Шекспира. Bla-bla-bla…

Рассказ Глеба Архангельского о «Философии управления временем» вернул мне утерянное было хорошее настроение. Мне, не дочитавшей до конца (кто бы мог предположить такое о control freak’е?) классическую работу «Getting Things Done» Дэвида Алена, посвящённый тайм-менеджменту доклад оказался довольно полезен. Неочевидная (хотя казалось бы) идея о невосполнимости времени жизни дала тему для раздумий. И правда, коли времени мало, логичнее тратить его в соответствии с личными целями (родными в противовес навязанным) и ценностями. Глеб перечислил несколько конкретных методик: «мемуарники», «лягушки», «слоны». Не буду давать расшифровку, на сайте http://www.improvement.ru/ они все есть, и с подробностями. Единственное, что несколько испортило впечатление, это неуклюжая анкета, предложенная всем присутствующим для заполнения. Требование обязательно указать в ней контакты человека, которому будут рекламироваться платные курсы, чем-то напомнило приёмы распространителей дешёвой косметики.

Следующий доклад, который я посетила, был посвящён «Производству IT-продуктов как способу оказания услуги» в исполнении Ольги Павловой. Общая идея состояла в том, что результативность проекта оценивается не по конечному результату, а по тому, как мы смогли удовлетворить заказчика, т.е. насколько хорошо смогли оказать услугу. Но важна не столько идея, сколько та детализация и глубина проработки вопроса, которая была нам продемонстрирована. Мне посчастливилось несколько лет работать с Ольгой в одной компании, и многое из того, что она говорила, вызывало очень конкретные, и не всегда приятные, воспоминания. Проблемы, негативные тенденции, риски – всё взято из практики, из опыта. Ольга сказала, что задача того, кто выдаёт фидбэк – подумать так, как вы думать не умеете. Я бы развила эту мысль – мне, разработчику, показали, как думают менеджеры. Ну хорошо, только очень хорошие менеджеры. И это необыкновенно полезно, потому что чем больше понимают друг друга участники процесса, выполняющие в нём разные роли, тем лучше общему делу. Резиновость приоритетов, которую неоднократно упоминала Ольга, я, как мне кажется, как раз и реализую у себя, выстраивая конвейерную разработку. Удержание качества работы, внутреннее, для себя, а не для заказчика – это то, к чему я стремлюсь. Единственное, с чем мне хотелось бы поспорить, это утверждение, что критика допустима только в рамках выступления, а в работе возможен только конструктив. Что, правда?..

(Не кстати, но упомяну, что Ольга сейчас готова рассматривать предложения о работе.)

Большая часть выступления Сергея Котырева «Национальные особенности в менеджменте» состояла из творческого, с хорошо подобранными примерами, пересказа основных принципов модели Cultural Dimensions, разработанной в 70х гг. Geert Hofstede (не буду пытаться транскрибировать имя). Пять критериев модели (Power Distance Index, Individualism, Masculinity, Uncertainty Avoidance Index, Long-Term Orientation) позволяют оценивать культуру общества или компании любого масштаба и, что интереснее, сравнивать их по полученным метрикам. Так, мы получаем научное объяснение, почему «что русскому хорошо, то немцу смерть», и это, конечно, весьма любопытно, но какое практическое значение может иметь? Сергей, по сути, предложил два варианты использования модели. Либо мы более осознанно подходим к особенностям русской культуры применительно к бизнес-процессам, построению команды, не удивляемся слишком сильно, принимаем и заранее раскладываем солому там, где гарантированно будет больно. Либо, и аудитория явно ждала конкретный список, мы используем метрики для выбора оптимальной страницы для эмиграции. Выбор между Уругваем и Испанией почему-то не очень вдохновляет.

Ну и хватит на сегодня.

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

И вдруг (не вдруг на самом деле, но очень неожиданно) ко мне стали подходить люди примерно с такими словами:
– Ты знаешь, а Ваня то как изменился. Он мне так помог…
– Не страшно, если ты занята сейчас, я спрошу у Вани, он в курсе…

Вот тогда я и задумалась.

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

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

Потому что иначе – несправедливо.

Я заставила себя. Я постаралась показать ему, что заметила, оценила, приняла. Что он получил level up и плюс пять к защите.

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

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

• Техногенная катастрофа. Любой набор причин, делающих невозможной работу в офисе. Нет электричества, закончился интернет, отказали кондиционеры (что стало неожиданно актуально этим летом в обычном промозглом Петербурге), перекрыты все подъезды к офису. Если в офисе делать нечего, или делать ничего не хочется (слишком душно, слишком холодно, слишком многолюдно из-за неожиданно нагрянувших гостей), работа вне офиса остаётся единственным способом добиться хоть каких-то результатов.
• Все ушли на фронт. Бывает, что офис вымирает по вполне радостным причинам – сотрудники уехали на пикник по поводу дня рождения фирмы или все нарядились и пошли праздновать Новый год / 8 марта / 23 февраля (нужное подчеркнуть). Подобные мероприятия не являются обязательными, и если кто-то хочет воздержать от участия в них – его право, при условии, что он в этот день работает. Бродить по гулким коридорам и пугливо оглядываться на звук шагов – слишком сильное испытание, да и ненужное. В такие дни работа из дома трактуется как небольшой подарок-замена общему веселью.
• Как будто из последних сил. То, за что у нас принято осуждать вслух и хвалить в глубине души – работа с температурой, преодолевая насморк и назло кашлю. Я никогда не требую ничего подобного от своих ребят, но, признаюсь, радуюсь, если они сами предлагают поработать из дома. Ну и сама грешна, каюсь…
  • Сюда же относится доблестное появление на работе в разгар зимних эпидемий – лучше работать удалённо, чем не работать вообще из-за гриппа с осложнениями.
• Мы едем, едем, едем… Можно отпроситься на несколько часов – уладить какие-то свои личные дела. Можно при этом попросить в такой укороченный день не приезжать в офис, чтобы не терять дополнительные рабочие часы на дорогу. Разрешу.
• Ну, ты понимаешь. Представьте себе, очень иногда и очень некоторым я могу позволить поработать пару дней из дома без особых причин, просто в качестве демонстрации моей признательности за их вклад в общее дело. Если кто из этих «некоторых» дочитал до этого абзаца – знайте и цените. :)

Понимая, что практически в любой день тот или иной сотрудник может оказаться вне офиса, я стараюсь учесть это заранее:

• Всегда на связи. Кажущаяся доступность интернет-каналов связи может сыграть злую шутку. Можно иметь аккаунты в нескольких программах обмена сообщениями – и оказаться отрезанным от мира при отключении интернета или электричества. Можно завести email’ы на десятках почтовых сайтов – и потерять доступ ко всей почте разом из-за слишком очевидного злоумышленнику пароля. Сотовый телефон может разрядиться, городской – отключен за неуплату. Способы связи с работающим из дома сотрудником, основные и альтернативные, запасные и резервные, всегда выбираются и проверяются заранее.
• Вход в Матрицу. О, это больной вопрос… Если работа в компании изначально планируется по удалённой схеме, проблем обычно нет, но как тяжело бывает получить какой-то специфичный доступ там, где безопасность системы стоит во главе угла. Приходится идти на компромиссы, выбирать и организовывать сознательно усложнённые способы управления внутренними ресурсами, хостами, серверами, данными. Бороться с дефолтным «нельзя» на все попытки организовать полноценную работу из дома. Разумеется, только с рабочего ноутбука. Разумеется, только через… И умолкаю, увы, тут подробностей не будет.
  • Важно осознавать, что никакие доступы не выдаются сразу, и потому список необходимого для каждого сотрудника должен быть составлен задолго до того счастливого дня, когда кому-то захочется поработать из дома.
  • Не только получить, но и удержать доступы иногда бывает непросто. Они могут исчезнуть из-за какого-то сбоя или после переконфигурации чего-то далёкого в системе. Следовательно, периодически надо проверять сохранность доступов.
• Скажи мне, кто твой … коммит. Как ни печально, вопрос контроля иногда всё-таки поднимается, и разрешить его простой констатацией доверия не всегда возможно. Работает ли сейчас сотрудник или пьёт чай перед телевизором? Ребята знают, что я имею привычку задавать по icq (или аналогам, не важно) вопросы, требующие немедленного ответа. И если ответ поступает через час – не уверена, позволено ли будет человеку ещё когда-нибудь работать так далеко от меня. Кроме того, обычно работа верстальщика оставляет вполне осязаемые следы – записи в багтрекере, отчёты на вики, коммиты, наконец. Отсутствие всего этого – повод для сомнений. Да, приходиться выступать в роли надзирателя. Да, это неприятно. Да, я это делаю.

Пожалуй, и хватит на этом. Одиннадцать вечера, я дома и мне пора делать серьёзное обновление на боевых.

Второе по важности место занимают качества, важные для тимлида. Мне нужно знать, кто и насколько легко сможет заменить меня, если возникнет такая необходимость. Кому я доверю выкладку релизов, уходя в отпуск? Кто вместо заболевшей меня пойдёт обсуждать будущее тех. решение крупного проекта? Кто подхватит управление пулом задач и сумеет распределять их между разработчиками оптимальным образом? Кто обладает наиболее глубокими знаниями о «чужих» компонентах? Как бы меня это не пугало, как бы это ни было обидно, я знаю, что не являюсь незаменимой, и потому заинтересована в том, чтобы тот, кто придёт на моё место (на неделю ли или навсегда) умел выполнять мою работу наилучшим образом.

Наконец, на последней позиции оказываются личностные свойства сотрудников. И я даже не о том, рискну ли я кому-то из них доверить свои маленькие секреты, нет. Могу ли я рассчитывать, что человек всегда будет приходить на работу вовремя? Можно ли в случае аврала надеяться, что сотрудник поможет решить возникшую проблему в выходные? Захочет ли? Будет ли на связи? Часто ли болеет и если да, то работает ли из дома? (Не надо возмущаться: я не прошу так делать, но – надеюсь, и никогда не забываю показать пример.) Курит ли и если да, то сколько времени проводит в курилке? Да-да, мне не лень лишний раз взглянуть на часы. Всё вместе складывается в ещё один сияющий красным коэффициент.

У меня в команде сильные разработчики, и я доверяю им – но неодинаково. Так, одному вечно приходиться проводить вместо меня выкладки на боевые, и он, бедняга, искренне расстраивается, когда я собираюсь в отпуск. А другому, например, дана полная индульгенция на проведение рефакторингов.

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

С оценкой качества кода всё немного сложнее:

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

1. Перед передачей в тестирование. Очевидно, что переделывать написанное, когда тестеры уже дали добро на выкладку, поздно.
2. Перед выкладкой после окончательной актуализации пакета. Ошибки на этом этапе выявляются редко, а вот рассогласование содержимого пакета с последними изменениями на продакшене – бывают.
3. В момент обновления боевых. Мы используем для деплоймента скрипты, которые, помимо прочего, показывают diff’ы выкладываемого пакета с предыдущей боевой версией. Признаюсь, я делаю это больше для собственного спокойствия, так как изменить что-то в этот момент уже невозможно.
4. Наконец, последний пункт, который, вероятно, стоило поставить первым, – в любой момент по просьбе разработчика. Посоветоваться, вместе придумать наиболее красивое решение, свежим взглядом окинуть кажущуюся нерешаемой проблему или просто передать часть задачи кому-то, кто справиться с ней легче, всё это я делаю регулярно, и регулярно же прошу кого-то из своих ребят помочь мне с моим кодом.

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

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

От доверия к контролю путь пройден, пора назад. Тому, кому я доверяю больше других, я доверю самое ответственное – контролировать меня.

Недоразумение номер два – причины, по которым я настаиваю на присутствии в указанное время:

1. Выкладка релиза – финал нашей работы, и потому организации беспроблемного деплоймента я уделяю большое внимание. Проверить правильность работы нового функционала, быстро разобраться в возникших проблемах, наконец, объяснить, держа в голове объёмную постановку, что вот это зелёное и квадратное – не баг, а заказанная фича, со всем этим лучше прочих справится тот разработчик, который непосредственно кодировал данный релиз. Из этого следует, что он должен находиться на «низком старте» непосредственно перед выкладкой, в процессе и несколько часов после. Идея участвовать в важной процессе удалённо не рассматривается, так как легко можно представить, как в момент Х разработчик отходит на кухню за чаем, отвлекается на хнычущего ребёнка или не успевает отогнать от клавиатуры любимого кота.
2. Помимо разработки у нас есть обязанности по участию в разборе инцидентов на боевой среде. Если на боевых происходит что-то странное, мы подключаемся, анализируем, предлагаем варианты спасения. Разумеется, в большей степени это обязанности лично моя, тимлида, но так свои способности я оцениваю более-менее адекватно (кто меня знает, молчите!), я осознаю, что в некоторых сферах отдельные разработчики разбираются лучше меня. Это означает, что системе в целом выгоднее, если в каждый момент времени будет привлекаться наиболее «сильный» сотрудник, тот, кто быстрее и качественнее разберётся в ситуации, заглянет в код, придумает обходной путь. Поскольку невозможно предугадать, что случится завтра и кто окажется наиболее востребованным, разумнее держать пул нужных специалистов всегда под рукой.
3. Наконец, необходимость двусторонней непрерывной коммуникации.
   • Если внутри команды можно назначать встречи на вечер, то с членами других отделов договориться может оказаться нелегко, а иногда и невозможно. Один раз отложить, другой – без вопросов, но на третий Москва захочет поговорить в девять утра, и надо присутствовать, и отвечать, и реагировать бодро и без зевания.
   • Жизнь на конвейере предполагает, что набор задач, над которыми надо работать в текущий момент, и постановка этих задач могут в произвольный момент времени измениться. Как тимлид расскажет об этом отсутствующему разработчику? В какой момент они сядут рядом ревьюить код? Как быстро разработчик получит ответы на уточняющие вопросы, заданные ночью, и сколько написанного кода придётся выкинуть из-за того, что тимлид только утром остановит несущийся в никуда паровоз?

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

Интересный вопрос, в какой момент должны проговариваться «правила игры». Я не требую от своих сотрудников ничего, о чём им не было бы сказано заранее: и в момент первого собеседования, и при оформлении на работу, и позже – неоднократно. Читать мои мысли они не обязаны, а мне, в свою очередь, не лень ещё и ещё раз рассказать, кого, когда и зачем я бы особенно хотела видеть в офисе.

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

Но что же я всё так формально, сотрудники да разработчики? Здравствуй, Вася.

Когда я поняла, что у Васи есть сложность (а у меня, соответственно, проблема) с соблюдением режима, я сделала две очень правильные, как мне кажется, вещи. Во-первых, я его не уволила. Поверьте, хотелось, и сильно. Во-вторых, я задумалась, почему вообще люди могут опаздывать на работу, и даже составила список, примерно такой:

• Не понимаю, зачем. Если у человека были нетребовательные родители, школа во вторую смену, институт с чужими конспектами и непохожий на меня предыдущий начальник, вполне может иметь место искреннее непонимание, зачем нужно приходить в указанное время. Объяснить, рассказать и убедить – значит взять на себя роль гонца, приносящего плохую новость. Увы… Мои аргументы перечислены выше, но, конечно, может быть и десяток других. Вася и другие мои сотрудники прекрасно с ними всеми знакомы.
• А что, нельзя было? Говорят, при дрессировке кошек нельзя вечером наказывать их за оставленные с утра лужи – они не вспомнят свою провинность и просто обидятся на хозяина. С людьми, прошу прощения, так же. Если сотрудник опоздал, надо сразу же показать ему, что он поступил нехорошо. Форма, разумеется, должна оставаться корректной, но при этом недовольство должно быть гарантированно донесено до адресата. Поминать опоздания задним числом бессмысленно, если только вы не хотите испортить отношения с человеком опять-этими-дурацкими-придирками. Следую ли я этому правилу сама? Да, и строго, вплоть до того, что не делаю замечания, если Вася пришёл на работу в тот момент, когда я выходила куда-то. Формально он опоздал, но к моему возвращению он уже старательно глядит в монитор, так что ругать поздно, только от работы отвлеку зря.
• Я как все. Неприятно, если рядом опаздывает кто-то ещё. Возникает соблазн выразительно кивнуть на пустующее по соседству рабочее место. Ужасно, если опаздываете вы сами. Нечестно требовать от других больше, чем вы готовы делать сами. Да и не сработает.
• Мне – можно. Видела, сталкивалась, знакома с такими звёздами от разработки. Они считают, что за идеальный код им простится всё – отсутствие на работе, игнорирование указаний и просьб, более чем вольный стиль общения. Если сотрудник незаменим, вам не повезло, придётся мириться с его «особенностями». Но я стараюсь таких людей избегать и в свою команду никогда не возьму – не стоит оно того. Что касается Васи, то ему свойственна скорее скромность в самооценке.
• Иди отсюда, девочка. Иногда (вот ведь неприятность) в коллективе случаются конфликты. Тогда нарочитые опоздания могут стать способом выражения пассивной агрессии, проявлением неуважения к руководству. Конечно, действовать это будет только на некоторых control freak’ов, но зато как сильно… Излишне говорить, что я долго пыталась понять, не обидела ли я человека, не спровоцировала ли чем-то его недовольство, не дала ли повод для затаённой злобы. Думала, вертела, пробовала мысль на зубок – но нет, не обнаружила со своей стороны ничего предосудительного. Вася, если я не права, подойди ко мне, поговорим.
• И без меня всё хорошо. Эту идею хорошо сформулировал в комментариях Иван Кузнецов: «Вася не чувствует себя важным. Он не чувствует важности своего прихода в 10 утра. Когда нет тимлида — важность появляется, потому что он на рубеже, на нем ответственность». Действительно, рассказ об абстрактном разработчике, который всех спасёт, не произведёт должного впечатления, если в реальности тимлид все вкусные проблемы и задачи будет стабильно забирать себе. А я, кхм… Неизвестно, кому было сложнее переломить себя, Васе или мне, заставляющей себя отдавать и делегировать принятие решений. Я научилась, и вот уже и выкладки делаю не только я, и на хитрые письма в рассылках отвечают все разработчики по очереди, и всё более и более серьёзные технологические вопросы решаются не мной (хотя, разумеется, под моим контролем). Если разработчик заслужил моё доверие, ему будет гарантированно не скучно. Заслужил ли его Вася? Пока не полностью, но прогресс явно виден.

Откладывать больше нельзя, пора, наконец, предложить способы воздействия на Васю.

• Поговорим? Процитирую Ивана Лысенко: «попробовал попрактиковать, к своему сожалению, телепатический стиль общения и он провалился в 9 случаях из 10». Общение и ещё раз общение. От меня – поток объяснений, аргументов, доводов. От Васи, в свою очередь, ожидается внятный рассказ о том, что же мешает ему приходить раньше. Готова допустить, что причины вполне убедительны, но я тоже не телепат, и если мне не сказать явно, я вольна придумывать объяснения сама, и они могут оказаться не в пользу Васи.
• Повторение – мать учения. То, что очевидно мне, вполне может казаться откровением кому-то другому. Если я знаю о важности завтрашнего релиза, Вася о нём вполне может не помнить, он давно занимается разработкой другого проекта. Я взяла на себя роль ремайндера – в конце концов, если мне так нужно видеть Васю завтра ровно в 11:05:30 у компьютера, мне не тяжело предупредить его об этом за день. (Кстати, и в семейной жизни приём полезный – не ждать, что о вашем делании догадается партнёр, а хотя бы намекнуть ему, если нет сил сказать прямым текстом.)
• Если нельзя, но очень хочется. Иногда я готова пойти на уступки. Разрешить работать из дома. Согласиться, что у конкретного Васи рабочий день начинается, например, с двенадцати. Как много я отдам – зависит в большей степени от того, чем в свою очередь готов поступиться, пусть и не явно, Вася. Просто так, к сожалению, ничего не бывает. Работаешь удалённо – значит, не участвуешь в выкладках, поэтому с большей вероятностью получишь в работу пакет попроще, для которого релиз будет проходной, быстрый и скучный. Приходишь позже – значит, не участвуешь в обсуждении проекта, следовательно, проект, интересный, сложный, с перспективами, достанется кому-то другому. Ну и премия за него тоже, мда… С Васей подобная договорённость существует.
• Положительная и отрицательная обратные связи. Я уже говорила, как важно сразу сообщать о том, что очередное опоздание замечено и учтено. На самом деле не менее важно и хвалить – за то, что пришёл, когда договорились, за то, что стал в принципе приходить раньше. Постоянно обращать внимание на хорошее, не концентрироваться на воспоминаниях о том, что было раньше, – ещё одно мучительно достающееся, но очень полезное свойство тимлида.
• Круговая порука. Вася не работает в вакууме, в отделе у него есть приятели и друзья. Почему бы не привлечь их к решению нашей с Васей проблемы? Например, можно предложить, чтобы Петя каждое утро нашего Васю будил телефонным звонком. Или попенять Васе, что из-за его опоздания часть работы пришлось взвалить на ни в чём не повинного Славу.
• Ты ещё пожалеешь! В комментариях мне несколько раз предлагали различные способы наказаний – от денежных штрафов до угроз увольнения. Я не верю в действенность подобных вариантов, и не применяю их в таком откровенном виде. С другой стороны, лишение интересных задач, уменьшение потенциальных способов заслужить премию, тоже может считаться наказанием, и тогда да, мне пора в очередной раз брать в руки кожаную плеть.
• А у меня есть блог. Наконец, последний способ, самый забавный, на мой взгляд. Можно дать Васе ссылку на обсуждение этого кейса. Вдруг он увидит здесь что-то для себя полезное.

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

• Control freak всегда лжёт.
• Control freak предупреждает, что следующее его высказывание – ложно.
• Control freak утверждает, что любит заниматься планированием.

Мне кажется, я могла бы больше ничего не писать, но всё-таки добавлю ещё несколько абзацев.

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

Моё везение закончилось: планирование, это чудище обло, озорно, огромно, стозевно и лаяй, нагнало меня и вцепилось мёртвой хваткой. О нём, этом монстре, я и хочу немного поговорить.
Зачем нужно планировать? Я подходила с этим вопросом к разным людям, и получала ото всех примерно одинаковые ответы:

• Чтобы иметь возможность заранее планировать публичные запуски.
• Чтобы заранее оценивать стоимость разработки той или иной новой функциональности.

Цели, безусловно, благие. Как, в идеальном мире, эти цели могут реализовываться? Рассмотрим два самых простых сценария.

1. Дата запуска известна заранее.
   1. Заказчик сообщает требуемую дату запуска (Z) и приоритет задачи по сравнению с уже поставленными.
   2. Тестеры называют точный срок, за который они протестируют заказанный функционал (T). Начало тестирования назначается на дату Z-T.
   3. Разработка называет точный срок, за который она реализует и подготовит к тестированию заказанный функционал (D). Требуемые ресурсы – в наличии, приоритет позволяет работать по задаче. Разработка начинается в момент Z-T-D.
2. Необходимо заранее назвать дату запуска.
   1. Разработка называет точный срок, за который она реализует и подготовит к тестированию заказанный функционал (D).
   2. Тестеры называют точный срок, за который они протестируют заказанный функционал (T).
   3. Дата запуска (Z) определяется как D+T+время ожидания задачи в общем пуле.
      • Время ожидания может быть нулевым для приоритетных задач и бесконечно большим – для мелких и мало кому нужных.
      • Иногда дата запуска не важна. В таком случае релиз выпускается по готовности, без предварительного согласования момента выкладки с заказчиком.

Что может происходить в реальности? А ничего хорошего. Спущенные сверху требования по датам могут оказаться либо полностью невыполнимыми, либо реализуемыми ценой авралов и переработок. В отделах может не хватать ресурсов – в нужный момент, или нужного типа. Наконец, оценки по трудозатратам могут оказаться ошибочными. Понимающий заказчик выслушает аргументы и умерит свои аппетиты. Но где такого взять?..

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

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

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

Так что, не планировать? Нет, никакого экстремизма. Пытаться планировать, обещать сроки, указывая зависимости и условия, при которых они могут быть выдержаны, максимально открыто делиться с заказчиком информацией, – всё это нужно делать, и делается. Но не перегружать планы излишней детализацией, сосредоточиться не на оценке результата планирования (обещали N запусков, а выполнили M, и при этом на T недель позже), а на выстраивании оптимальных процессов в разработке, в каждой команде, в каждой группе. Добиться того, чтобы релизы выпускались так часто, как это возможно, чтобы никакие задачи не замораживались на неопределённый срок, чтобы каждый член команды хотел улучшать общую систему и работал на пределе своих возможностей. Честно. И быстро.

Реплика в сторону:
Вы заметили, какое мягкое слово я выбрала – «раздражают»? А ведь подумала я совсем, совсем по-другому. Но вдруг мои тексты будут читать дети…

Начну с того, что я не принимаю и не понимаю подобную расхлябанность. (Название моего блога помните? Ну вот то-то же.) Не высыпаешься? Ложись раньше. Не можешь лечь раньше, так как не успеваешь закончить запланированное? Займись тайм-менеджментом. Не слышишь будильник? А ты его не забыл завести? За подобными дошкольными объяснениями маршируют обычно суровые студенческие аргументы. Я лучше работаю по ночам, потому что я сова, стрелец, Есенин, нужное подчеркнуть. Моя производительность зависит от солнечной активности, лунных затмений, приливов в океане, положения Марса в доме Венеры (ох, я отвлеклась). Следом двигается тяжёлая артиллерия. Если кому-то обязательно нужно поговорить со мной лично, это потому, что он не умеет писать письма. Если письмо не ждёт до завтра, значит, у вас плохо выстроены процессы. И как-то же Америка отдаёт тех. поддержку в Индию, так чем мы хуже? Себе любимому можно позволить очень многое, это правда. Но – только до тех пор, пока это не мешает делу. И это подводит нас ко второму пункту.

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

Дисклеймер:
Вообще-то я знаю, что бывает работа, допускающая абсолютную дистанционность и оторванность от реального времени. Она называется freelance – и пусть себе будет, я сама когда-то подвизалась в этой области. Мне сейчас просто не интересно об этом говорить, я пишу только о работе в крупных командах.

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

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

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

Очень интересно прозвучала идея о двойном применении принципа Парето к решению поставленных задач. Тратим 20% усилий, получаем 80% результата, затем переформулируем задачу и снова делаем только 80% заказанного – но получаем суммарно 160%. Формально странная, на практике эта мысль реализуется в следующем: за время пути «собачка» настолько сильно подрастает, что ей уже и старый ошейник, который мы так старательно шили, начинает жать, и интересы её полностью переключаются с игрушечных косточек на вполне живых соседских пуделих. Сколько раз за время разработки отпадала необходимость в таком желанном когда-то втором этапе проекта? Вот то-то и оно.

Далее разговор зашёл об оценке требований. Применение принципа Парето к ним сводится, по сути, к выкидыванию всего, что противоречиво, плохо сформулировано, долго или дорого в реализации и так далее. Здесь прозвучало то, что заставило меня поёжиться: получив 20% требований, мы начинаем их реализовывать, получаем первую версию и идём к заказчику – рассказывать, что именно это ему и было нужно. Вы видите тут подвох? Я вижу – мы не согласовали с заказчиком списки как оставшихся требований, так и отвергнутых. Представляю в красках эту картину: вот заказчик устраивает скандал на тему «почему меня не предупредили» (и будет прав), а вот мы выкидываем результат многомесячной разработки потому, что в процессе кромсания исходных требований выкинули то единственное, которое было нужно заказчику любой ценой – долго, дорого, на лыжах, как угодно.

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

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

Руководя отделом, работающим по конвейерной схеме, я периодически ощущала себя тем муравьём, вынужденным соизмерять свой темп с неторопливостью команд, выпускающих связанные с моей компоненты.

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

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

1. Знаем о смежной команде всё.

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

Не менее важно понимать, каким образом у соседей выполняются те или иные работы. Пусть нам для сборки релиза достаточно, по сути, указать ветку в системе контроля версий. Может оказаться, что другой команде для подготовки релиза нужно два часа на сборку пакета и подготовку конфигов, например. И если вёрстка разворачивается на тестовом слое за секунды, на настройку серверной части могут уходить минуты, если не часы.

2. Встраиваемся в чужой процесс.

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

1. Мы начинаем учитывать внешние планы как свои собственные. Рассмотрим конкретный пример. У команды, выпускающей серверную часть нашего портала, на 1е июля запланирован выпуск релиза. Заказы в этом релизе таковы, что от нас требуется:
   • Выложить изменения, поддерживающие релиз, до его запуска. Для нас это просто пакет с внешним дедлайном, причём в наших интересах запустить его как можно раньше, чтобы ни в коем случае не задерживать выход релиза, если вдруг его сроки сдвинутся назад, на июнь, например. Ставим себе цель – закончить выкладки до 15го июня; две недели – достаточная фора для будущего релиза.
   • Собрать вёрстку, предназначенную для выкладки синхронно с релизом серверной части. Я уже говорила, что часто при планировании работ нам важен не срок их начала, а дата окончания. При синхронизации с чужими релизами это верно как никогда. Наша задача – узнать, когда по интересующим нас заказам начнутся работы, когда они перейдут в такую стадию, на которой нам уже имеет смысл подключаться, и когда результаты совместной работы должны быть переданы в тестирование. Опираясь на эти даты, мы определяем, насколько можно отложить разработку на нашей стороне, чтобы сэкономить впоследствии на актуализации пакетов. Начинаем верстать так, чтобы закончить разработку (на нашей стороне) и общее тестирование релиза к концу июля.
   • Подготовить набор правок, которые зависят от изменений в релизе и могут быть выложены после его запуска. Иногда возникает соблазн включить такие правки в пакет из предыдущего пункта. Не стоит: этим мы только замедлим тестирование, и, значит, поставим под угрозу запланированную дату выхода релиза. Июль наступил – и мы вольны распоряжаться своим временем.
     • Оговорюсь, что сдвигать работу над нашими задачами на даты после запуска базового релиза можно только в том случае, когда изменения в релизе могут быть протестированы независимо, а не через наш компонент.
2. Мы заранее вписываемся в чужие планы, даже если пока не можем поставить точные заказы. Иногда для реализации наших задач нам приходится выступать в роли заказчика для других компонент. И часто бывает так, что потребность в таких дружественных заказах возникает неожиданно, когда все планы уже давно подготовлены и утверждены. Что же делать?
   • Хороший вариант, хотя и непростой – договориться. Внести изменения в план, найти недостающие ресурсы за счёт других, менее приоритетных заказов. Вам пригодится всё ваше умение вести переговоры, убеждать и упрашивать. Любимое пиво тимлида нужного отдела, ваша короткая юбка (да, не самый универсальный совет, понимаю), наконец, железобетонная аргументация, почему оно нужно сейчас, срочно и обязательно, – всё пойдёт в ход.
   • Иногда договориться невозможно: либо выстроенные процессы не допускают гибкости, либо у вас нет личного контакта с нужным тимлидом. Не важно, в любом случае правильнее подстелить солому заранее – поучаствовать в формировании планов потенциально интересных вам отделов и добиться, чтобы в план были включены ваши будущие заказы. Оценить примерно их количество и сложность, и не ошибиться слишком сильно, чтобы не потерять право добавлять такие абстрактные заказы в будущем, – ваша задача. С опытом, с прокачанными навыками оценки входящего потока задач и прогнозирования будущего потока, придёт умение верно предугадывать загрузку не только своего, но и смежных отделов.

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

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

(Поскольку от любви к спискам мне не избавиться, использую их и здесь.)

• Докладчики, вызывающие восторг. Редко, очень редко встречаются на конференциях люди, чья речь, чьи выступления вызывают одновременно зависть (и почему я так не умею?) и восторг (неужели отведённое время уже закончилось?). Первенство в этот раз безусловно достаётся Вадиму Макишвили с докладом-размышлением на тему «Ошибка. Осознание, анализ, извлечение пользы». Причина даже не столько в близости мне затронутых проблем (как принимать собственные ошибки, как извлекать из них пользу), сколько в форме подачи материала. Вадим, конечно, не разработчик, не руководитель группы – он актёр, и прекрасный. Как иначе объяснить его умение держать зал, управлять голосом и интонациями, изящно переключаться с технических подробностей на этические дилеммы. Очень приятное впечатление произвела Екатерина Рощина с докладом «Top-20 глупых высказываний о QA и что на них ответить». Всё чётко, чётко, чётко. Кажется, содержание доклада не вполне соответствовало заявленной теме, но в любом случае послушать, что происходит в голове у тестировщиков, было интересно. Очень трогательно прозвучали предположения о том, что чувствуют разработчики по отношению к тестерам, на что обижаются. Но поскольку я сама иногда ловлю себя на желании порассуждать о сотрудниках других команд (тестерах, саппорте, менеджерах), упрекнуть Екатерину мне не в чем. Печально было в очередной раз услышать о том, что распараллеливание тестирования – недопустимое зло, тогда как для работы на конвейере такое ограничение неприемлемо. Профессионально зажигал Эндрю Босуорт, хотя и не совсем об обещанной «Engineering Culture at Facebook». Второй раз попадаю на доклад о facebook, и второй раз начинаю восхищаться совершенно, если вдуматься, ненужной мне системой.
• Доклады – источники информации. С интересом и, надеюсь, некоторой пользой в будущем, послушала доклады «СSS анимации в боевых условиях: преимущества и недостатки» Сергея Чикуенка и «CSS‐менеджмент. Три года спустя» Вадима Макеева. А рассказ Ростислава Чебыкина «Веб‐типографика» неожиданно подарил повод на IT-конференции вспомнить о другой вёрстке, которой я периодически занимаюсь, не xsl’ной, – о вёрстке книг. К сожалению, принцип «во многих знаниях – многие печали» в данном случае подействовал как никогда. Имеющийся опыт вёрстки пары десятков книг не позволяет мне всерьёз думать о внедрении типографики в веб, по крайней мере не той «большой» типографики, которая вырастает из чтения справочников Мильчина и изучения примеров качественной вёрстки по изданиям 50х годов. Полгода назад я была бы абсолютно счастлива докладом Николая Мациевского «Реалити шоу: 5x разгон сайта за 10 минут», но к сегодняшнему дню мне до всех описываемых им тонкостей пришлось дойти самой.
• Доклады, с которыми хочется поспорить. Масса докладов была посвящена Скраму: и «Почему нужно использовать Скрам в вашем веб-проекте. Опыт Моего.Круга» Евгения Курышева, и «Быстроменяющиеся требования и фиксированные бюджеты» Дениса Ермакова, и многие другие. Подозреваю, я слышала то, что готова была услышать: что Скрам может казаться панацеей только если до его внедрения процессы вообще не были выстроены; что привычка к коротким спринтам постепенно убивает умение планировать глобально (Денис Бугров, «Хроники окопной войны»); что попытка продать заказчику разработку на Скрам часто обречена на неудачу (и правильно, продавайте результат, а не процесс). В одном из докладов впервые услышала прекрасный термин «planning poker» – явный кандидат на погуглить в свободную минуту.
• Скучные доклады. Нет, здесь никаких имён не будет.

Спасибо организаторам за то, что свели вместе такое количество интересных докладчиков. Спасибо в больших кавычках за работающие в режиме «мы на Мальдивах» кондиционеры. Апхи и до новых, надеюсь, встреч.

• Время передёргивания «рубильника» должно быть несоизмеримо меньше необходимого на выполнение выкладки. Если это условие не выполняется, стоит сравнить стоимость реализации и тестирования «рубильника» по сравнению с подготовкой ещё одного релиза.
• В некоторых случаях необходимо разнести во времени релиз как момент появления функциональности на боевых серверах и включение новой функциональности для пользователя. Это означает, что при наступлении часа X (публичный запуск нового сервиса, с рекламой и фанфарами) времени на выполнение релиза (и возможности откатиться при обнаружении проблем или недоделок) уже может не быть.

В каких ситуациях может понадобиться создание «рубильника»:

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

Вариантов реализации «рубильника» мне известно немного:

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

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

Увы, подробнее говорить не имею права, но поверьте, несколько раз наличие «рубильника» спасало нас от очень, очень серьёзных неприятностей. Чего и вам желаю.

Вторая группа доводов содержала грустные примеры непрофессионализма тестировщиков. Увлечься лежащей на поверхности мелочёвкой вместо глубинной проверки базовых test case’ов, работать медленнее, чем планировалось, излишне формализировать свою работу (не брать проект в тестирование без описанных use/test case’ов, документации по проекту, etc), вмешиваться в процесс разработки, наконец, просто пропускать баги – конечно, всё это может сказать на качестве результирующего продукта, но и в этом виноваты не тестеры в целом, а только конкретные их представители. Научить или уволить – других вариантов нет.

Наконец, третья группа обсуждавшихся вопросов сводилась к наиболее интересным мне проблемам – к неправильно построенным процессам. Мы услышали несколько и забавных, и ужасающий примеров, как, например, из-за возможности заказчика влиять на тестеров, или из-за передачи тестерам права самостоятельно и окончательно принимать решение о запуске продукта, чуть ли не самолёты падали. Вина ли это тестировщиков? Безусловно нет. Они работают в очерченных им рамках, берут на себя ровно столько ответственности, сколько им дают. Выстроить оптимальные отношения между заказчиком-менеджером-разработчиком-тестером – вот всё, что нужно на самом деле. О, это моя тема!

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

От встречи в целом, и от официальной части, и от неформального общения после, остались самые приятные ощущения. Спасибо организаторам и всем участникам. И если меня, болтливого не тестера, пустят на ту сторону баррикад ещё раз, приду с удовольствием, ибо узнавать, о чём думают тестировщики – и интересно, и полезно.

• Что? Проверка выложенных изменений. Кто? Разработчик, который знает, как быстрее всего попасть на новую страницу, у которого заранее созданы пользователи в необходимых состояниях, который не спал накануне, ворочаясь с боку на бок от смутных предчувствий. Да, интуиция, прозрение, предвидение – такие же инструменты разработчика, как и глубинные знания технологий и спецификаций. Заказчик, которому не терпится первому увидеть заказанный функционал в действии. Тестер, которому после тщательного тестирования уже ничего не стоит ещё раз пробежаться по знакомым test case’ам.
• Что? Проверка общей работоспособности системы. Кто? Тестер с помощью автоматических тестов. Да, автотесты запускались перед выкладкой, да, на тестовой среде проблем не обнаружилось. Но кто знает, чем могут отличаться конфигурации боевых и тестовых серверов, и как повлияет на функционирование портала реальная нагрузка? (И не говорите мне про нагрузочное тестирование – знаю, помню, использую. Но многим ли оно доступно? И будут ли заранее проверены под нагрузкой все релизы, включая самые мелкие и с виду невинные? А если честно?)
• Что? Поиск невидимых пользователю проблем в логах портала. Кто? Эксплуатация. Пусть визуально всё хорошо, пусть кажется, что новый функционал успешно включён. Иногда только админу под силу заметить признаки приближающейся беды, анализирую логи и оценивая нагрузку на сеть, железо, базы данных и связанные компоненты. Разобрать же логи после успешного релиза, обсудить полученные данные с разработкой – правила хорошего тона для каждого админа.
• Что? Получение первого feedback’а от пользователей. Кто? Служба поддержки. Не зря мы предупреждали саппорт о точном времени включения нового функционала. Не зря рассказывали, на какие жалобы стоит обращать особое внимание. Если только ваши тесты не покрывают имеющуюся функциональность на 100% (и я вам завидую, если это так!), всегда найдутся страницы, до которых дотошный пользователь доберётся раньше вас.
• Что? Отслеживание изменений в поведении пользователей. Кто? Менеджер, заказчик, кто-то, кто имеет доступ к статистике и умеет её анализировать. Мы ведь ещё помним, ради чего релиз выпускали, не так ли?

Чего ждём? Невозможно уделять одному релизу слишком много внимания, следующий уже на подходе. Полезно ещё до выкладки решить, через какой период времени стоит ожидать тех или иных результатов:

• Если релиз можно полностью проверить самостоятельно и быстро, достаточно выждать часа два, и можно спокойно переключаться на следующие задачи. О проблемах скорее всего станет известно сразу после выкладки, так что если вы прожили с новой версией портала час, проживёте и день.
• Если выкладка была сложной и заранее известно, что результаты работы нового функционала появятся через день, через два, попробуйте распланировать свой календарь релизов таким образом, чтобы в эти дни ничего больше не выкладывать. Тогда в случае возникновения каких-то сложностей вы с большей точностью назовёте их причину. Иногда наслоения изменений лучше избегать.
• Бывают релизы, момент появления данных для оценки которых можно планировать весьма приблизительно. Например, мы знаем, что сможем собрать нужную статистику только через пару недель. Или заказчик сообщил нам, что начало активного завлечения пользователей на новые страницы откладывается на следующий квартал. Ждать в таком случае не стоит, но помнить – обязательно.

Всё пропало! Не у меня, конечно, и, надеюсь, не у вас, но у кого-то выкладка может пойти не так, как ожидалось. Что должен делать этот несчастный кто-то при обнаружении проблемы после релиза?

Первое правило, высеченное в камне, выстраданное: немедленно откатываемся! Искать причины, придумывать фиксы, назначать (если это у вас принято) виноватых – всё это следует делать только после того, как проблемный релиз убран с боевых. Даже если очень хочется оставить. Даже если вы точно знаете, где подкрутить, чтобы оно заработало. Нет, нет и нет. Девять раз правка «по живому» спасёт, но на десятый может стать так больно… И этот неудачный раз, когда по вашей вине случился out of service, вам будут припоминать очень и очень долго.

К сожалению, бывают неоткатываемые релизы. При возникновении проблем после такой выкладки, увы, придётся готовить быстрый фикс. Что тут скажешь? Удачи, спокойствия, выдержки.

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

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

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

Честность оценок и обещаний. Иногда у заказа есть deadline, обусловленный причинами такой значимости, что на его выполнение необходимо бросить все доступные ресурсы и переключаться в режим 24х7 напряжённой разработки. Но – только иногда. Чаще всего срок, пришедший вместе с задачей, является всего лишь пожеланием. Принимая его от заказчика, сравните со своими оценками – совпало? Если нет – не скрывайте ни своей способности выполнить заказ раньше (и, разумеется, не упускайте возможность продемонстрировать свою скорость и организованность), ни необходимости значительно сдвинуть дату запуска (лучше сразу предупредить о нереальности поставленных сроков, чем преподносить неприятный сюрприз в последний момент). Вы пытаетесь планировать результат чужой работы, работы менеджера по подготовке заказа к передаче в разработку? Так помогите менеджеру планировать вас.

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

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