Наверх ▲

Как работать, когда работать некому

Евгения Фирсова Евгения Фирсова Руководитель отдела веб-интерфейсов, Яндекс.Деньги.

Евгения Фирсова: Добрый вечер! Меня зовут Евгения Фирсова. Я хочу сегодня рассказать или, если угодно, определиться и пожаловаться вслух на большом зале (мне приятно жаловаться вслух) о том, как работать, когда работать некому.

Представьте себе: у вас все хорошо. Молодой человек в заднем ряду, который сейчас очень тщательно представляет что-то такое про романтический вечер! Не надо. Я не это имела в виду. 

Представьте себе, что у вас все хорошо на работе.

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

Вдруг это ощущение комфорта, ощущение, что у вас все хорошо, уходит. 

Оно, конечно, может уйти по сотне разных причин. Мне сегодня интересны две.

Причина номер один: когда у нас возникает непредвиденный дефицит ресурсов. 

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

Первые две минуты, когда такое происходит (я не знаю, что делаете вы), я думаю: «Ах ты, предатель!». Еще всякие слова думаю, просто не будут со сцены озвучивать. Потом я начинаю задавать себе вопросы относительно позитивные, пытаюсь понять, что, собственно, произошло, почему люди ушли. Это важно. Я потом скажу, почему важно.

На слайде перечислено несколько моих представлений о том, почему люди уходят.

Бывает, что разработчик вырос из задачи. Ему стало неинтересно. Или чувствуется, что он не развивается в профессиональном плане. Вообще говоря – имеет полное право. 

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

Это повод задуматься. Может быть, что-то пора менять: застой.

Может быть, разработчик вообще занимается не своим делом? 

Это странно, но я видела такие ситуации, что разработчик становится экспертом в области usability или начинает рисовать картинки. Разработчик начинает очень активно общаться с менеджерами, с постановщиками и вообще уходит на уровень аналитика. То есть он уже делает не то, что он как разработчик должен делать.

Иногда бывает, что разработчик (у меня такое было, правда) начинает выполнять частично мои обязанности как тимлида. Тогда это хороший повод задуматься: может быть, это и не ужасно? Только не надо его отпускать на сторону. Если он дорос – давайте ему это дадим. Давайте делегируем ему часть моих или чьих-то обязанностей. Это вполне вариант удержать человека.

Если разработчика переманили – естественный вопрос: может, мы даем мало денег? Кто дает больше? Вообще очень интересно узнать, куда ушел, на какую зарплату, какие условия. Я прилагаю к этому определенные усилия, потому что мне надо знать. Я любопытная.

Бывают какие-то мелкие вещи, на которые можно долго не обращать внимания, пока не «клюнет». 

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

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

Еда. Например, бывают люди, которые не едят мясо. Что у нас в столовой? Возможность заниматься спортом. У нас есть спортивный зал или нет?

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

Почему они уходят. Что им не нравится. Естественно, они не скажут. Или скажут что-нибудь, не соответствующее действительности. Но интересно. 

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

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

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

Бывает, что вам, мягко говоря, не повезло. Руководство меняется, или старое руководство просто имеет такой стиль: «Я хочу, чтобы оно было завтра, и мне все равно как». Если такой стиль управления превалирует, то ваши возможности, интересы и желания вообще не учитываются. К вам пришли и сказали: «Теперь ты делаешь – вот список. Как хочешь – хоть чучелом, хоть тушкой». Бывает.

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

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

Когда происходит первое и второе одновременно, это очень печально. У меня, на самом деле, случилось именно так. Поэтому я с чистой совестью сегодня вышла на сцену, чтобы поделиться наболевшим. У меня немного стали уходить люди по разным причинам. Мне повезло – мне показали список задач на ближайшие полгода. Список был таким, что даже если бы люди не ушли… В общем, «похороните меня за плинтусом», что называется.

Я вообще человек ощущений, я доверяю собственной интуиции, но это не работает в профессиональном плане. Одно дело – я чувствую, что мы не справимся с этим объемом задач. Другое дело – когда это надо кому-то аргументировать, показать в цифрах, графиках, метриках. Хочется эту проблему пощупать более предметно. Способы есть. Есть некие симптомы, на которые надо обратить внимание, потому что это оно самое. 

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

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

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

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

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

Наконец, бывают жалобы. Я так понимаю, в зале большая часть – все-таки менеджеры. Вам, наверное, приятно узнать, что на ваши жалобы мы, разработка, обращаем внимание. Да если бы мы сказали: «Да ты не прав…».

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

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

Когда возникает ощущение, что нам не хватает ресурсов, нельзя идти к генеральному директору и говорить: «Хочу людей, хочу вакансию». Нужно посчитать, какой ресурс у нас на самом деле есть. 

Традиционно все считают по головам. «У меня в команде 10 разработчиков». Это что? Это ресурс из десяти человеко-дней? Нет. 

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

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

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

Когда я разбила нашу деятельность на некие довольно крупные потоки, стало ясно: эту вещь умеют реально делать два человека. Если один заболел, а второй ушел в отпуск, мы вообще некомпетентны в какой-то области. Очень печально.

Бывают вещи, про которые вообще обычно не знают никакие заказчики, которые выкатывают пул задач. Это какая-то наша внутренняя деятельность, внутренний рефакторинг и какие-то технологические зависимости, которые тоже нас ограничивают в свободе распределения ресурсов между задачами. Например, недавно мы сделали очень-очень большой рефакторинг. Такой, что прямо версия портала 2.0. Никто не заметил – ни пользователи (слава Богу), ни менеджеры, хотя я им тоже продавала рефакторинг под маркой каких-то бизнесовых фич. 

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

Когда мы поняли, сколько у нас есть ресурсов, меня спросили (мне повезло): «Сколько тебе надо людей, чтобы покрыть какой-то пул задач?». Это очень сложно понять. 

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

Есть несколько вещей, на которые надо обращать внимание, планируя, сколько еще вакансий можно попросить.

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

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

Нужно пытаться угадать, какова вероятность, что поменяются приоритеты среди тех задач, которые есть, что поменяется вообще направление развития. Вдруг в какой-то момент все дружно поняли, что у каждого второго iPhone, Android, – давайте делать мобильные версии. Это было направление, которое надо было почувствовать. Хорошо, мы успели и сделали. А могли бы не успеть. Кто знает, что там будет завтра и насколько мы заранее сумеем соломы подстелить и найти нужных людей.

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

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

Так или иначе, мы пытаемся оценить: мне нужно столько-то людей, пытаемся договориться, чтобы столько вакансий нам дали.

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

Первое, что нужно сделать. Традиционно: ничего не делать, а только говорить. 

Мы переходим в авральный режим работы, и мы честно об этом говорим всем, кто хочет и не хочет нас слышать. Это накладывает определенные ограничения и на нас, и на тех, кто с нами работает.

Если мы вдруг по какой-то причине не делали этого раньше, начинаем очень открыто планировать. Все наши проблемы, вся нехватка ресурсов, вся невозможность сделать то, что от нас хотят, должна быть видна наружу. Это не мои ощущения, это не моя лень (не подумайте) – взять какую-то задачу и сделать реально в те сроки, которые обозначены. Есть ресурс, он распланирован на 10 задач. Вы хотите 11-ю – какую из этих десяти выкидывать? Надо делить ответственность за принятие такого рода решения с теми, кто готов эту ответственность на себя взять (менеджеры, заказчики – тот, кто решает). 

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

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

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

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

По крайней мере, в той области, где я работала (XSL-разработке), найти крутых, готовых профессионалов очень сложно. То есть, нет, легко – в соседней комнате, где большой Яндекс сидит. Там этих XSL’щиков… Но почему-то не очень хорошо их оттуда переманивать.

Вообще найти людей очень сложно. Поскольку найти надо быстро – мы в аврале и работать в авральном режиме долго невозможно – снижаем требования при найме. Мы соглашаемся брать junior’ов. Что это такое. Понятно, что я готова взять человека без практического опыта (откуда взять?), но предполагаю, что какие-то спецификации на (неразборчиво, 19:12) человек уж всяко прочитал. Глупо платить человеку зарплату за то, чтобы он сидел и читал документацию, которая выложена в интернет.

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

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

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

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

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

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

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

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

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

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

Брать новичков, не брать – так или иначе что-то придется менять в том, как вообще построена работа в вашей команде. Понятно, что все зависит от того, как вы вообще работали в вашем нормальном режиме, неавральном.

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

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

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

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

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

Затем они делают задачу вместе. Причем я очень слежу, чтобы вместе – это не XP. Мы готовы выделить каждому по компьютеру, никакой экономии. Задачи распределяются более или менее равномерно. Не то что один делает сложные бизнесовые решения, а второй CSS’ки правит. Нет. Но опытный просто контролирует совместный результат, он несет за него ответственность. 

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

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

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

У нас компании вообще очень везет: все приходят и навязывают свои процессы. Мы вынуждены. С объяснением, что это временно, что это аврал.

В любом случае если вы внутри себя что-то такое подкрутили, людей набрали, даже как-то научили, чудес не бывает. Все равно мы чем-то платим. Про нервы я уже сказала. Нервы не считаем. 

Конечно, сроки выполнения задач все равно упадут. Временно, у некоторых, но важные дедлайны все равно… Чудес не бывает – упадут сроки.

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

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

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

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

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

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

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

Помимо того, что происходит в компании, хорошо смотреть наружу. Есть некие «модные» тренды. Войти в интернете в денежные сферы, скажем так. Очень хорошо за ними, по крайней мере, попытаться следить. Чтобы те же мобильные приложения не стали неприятным сюрпризом. Чтобы то же развитие API, которое сейчас так любят все, не стало неприятным сюрпризом.

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

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

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

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

На этом я заканчиваю, готова ответить на вопросы. Спасибо.

(Аплодисменты).

 

Вопросы и Ответы

Вопрос из зала: Кондратьев Николай, Mail.Ru. Была очень интересная тема про пары. Как-то учитываются личные взаимоотношения этих людей при построении таких пар?

Евгения Фирсова: Да, это практически первое, что учитывается. Если я верю, что люди в перерывах, грубо говоря, играют в бильярд, это пара. Если я верю, что они обедают за разными столами, это не пара. Нельзя заставлять и навязывать, что они вместе будут развивать одну технологию. Это не в кайф, а в таких вещах должно быть в кайф.

Вопрос из зала: Еще один маленький вопрос на ту же тему. Насколько эти пары долгоживующие? Это навечно…

Евгения Фирсова: Нет-нет-нет. Эти пары только на тот период, когда нового человека надо активно ввести в курс дела. Затем просто есть какой-то круг общения. Не все вопросы обсуждаются на всех разработчиков. Это бессмыслица. Есть люди, про которых мы знаем, что они интересуются этой темой. Они уже работали с каким-то классом задач. С ними это обсуждается. Просто новичок включается в обсуждение такого рода вопросов.

Вопрос из зала: Спасибо.

Вопрос из зала: Добрый день! Александр, компания (неразборчиво название, 34:06). Если, не дай Бог, такой большой пул задач схлынет – что ребятам-то делать?

Евгения Фирсова: Хороший вопрос. К счастью, я не знаю, как на него отвечать, потому что я знаю, что у нас он не схлынет. Только это меня спасает. 

(Аплодисменты).

Вопрос из зала: Спасибо за доклад, Евгения. В прошлом году вы рассказывали доклад про скорость разработки. Тогда я задавал вопрос про выгорание ресурсов. Вы ответили, что от вас люди просто так не уходят. Изменилось ли что-нибудь за этот год? Как вы решаете эту проблему?

Евгения Фирсова: Да, изменилось. Хорошо, я скажу честно и откровенно, хотя вообще не планировала. От меня ушло два разработчика. Это, может быть, немного. У нас, в принципе, небольшие команды. Моя команда была небольшая. 

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

Вообще надо понимать, что, может быть, специфика наша. Мои разработчики должны знать не только XSL. HTML, JavaScript. Очень многим интересен JavaScript настолько, что они прокачивают себе dead skill на наших задачах и уходят куда-то заниматься именно JavaScript. Я не имею возможности предложить им задачи такого уровня, потому что нам не надо. У нас нет очень сильной завязанности на JavaScript, на динамические интерфейсы. Это ситуация, когда люди переросли наш уровень задач. Они очень сильно выросли у нас, и дальше им уже не должно быть у нас интересно. Это честно.

Но все равно я расстроилась. Зато презентацию сделала. 

(Аплодисменты). 

Вопрос из зала: Добрый день! Денис Бесков. Сколько времени в среднем занимал вывод новичка на нормальный уровень производства? Сколько времени в месяц на это тратил ведущий специалист, эксперт?

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

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

Вопрос из зала: Вы говорили про то, что вовлечение старшего специалиста требует времени. Он занимается обучением, а не производством. Какова эта загрузка?

Евгения Фирсова: Да, на этот вопрос я могу ответить. Поскольку это был фиксированный временной диапазон (то, что у нас сейчас происходит), получалось следующим образом. Я сама как тимлид примерно 60% своего времени тратила на разработку. Я была еще и в роли честного разработчика. Так же верстала, так же релизилась.

Когда возникла необходимость активно учить людей, или искать людей, или разбираться с тем, как мы теперь живем, времени, которое я лично трачу на разработку, осталось где-то порядка 10%. 50% моего времени как тимлида ушло на это. Чтобы новые люди пришли (чтобы я их нашла) и чтобы они стали выдавать тот результат.

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

Вопрос из зала: Спасибо.

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

Евгения Фирсова: Во-первых, я, конечно, попытаюсь узнать теми средствами, которые мне доступны, что там у нас планируется. Узнаю, не узнаю – другой вопрос. Я, конечно, не могу брать под эту несуществующую задачу человека – я не аргументирую это. 

Но да, я буду поощрять своих разработчиков на исследования в этой области. У нас есть договоренность. Где-то 10% своего времени они могут тратить не на мои задачи, которые я дала, а на эксперименты, чтение документации, исследование своего, чужого кода, кода третьей стороны. Я могу им сказать: «Эти кто-то, кто хочет, поисследуйте немного в эту сторону». На некоторых технологиях (не мобильных версиях, а других) у нас сейчас такое происходит.

Вопрос из зала: Спасибо. Немного личный вопрос, но многим, наверное, тоже будет интересно. Что вы так долго блог не обновляете? Как-то грустно даже. Хороший же.

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

Вопрос из зала: У меня сразу третий вопрос возник. Как вы заставляете своих ребят перерабатывать? Какие аргументы находите.

Евгения Фирсова: Я говорю: я не заставляю.

Вопрос из зала: Но все равно же приходится как-то объяснять.

Евгения Фирсова: Если вдруг такое происходит (это происходит очень редко), я им объясняю, почему возникла такая потребность. Не вообще – поработать не успеваем, а «есть дедлайн, заявлен публичный анонс запуска сервиса, тестеры нашли в последний момент три новых бага. Пожалуйста, поработай в субботу, а потом возьми этот день отгулом после запуска». 

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

Вопрос из зала: Ясно. Спасибо.

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

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

Конечно, есть некий диссонанс, потому что это очень легко – дать человеку прокачать какой-то skill. Это удобно. Он один раз сделал задачу, следующую аналогичную я дам ему. Мне как тимлиду так проще. Я получаю гарантированный результат. Быстрее, потому что человеку задача знакома. То, что это проблема, видишь не сразу. Хорошо, я увидела не сразу, что это проблема. Даже не потому, что человек ушел вообще. Он может, не дай Бог, заболеть, он может в отпуск уйти. Я же не могу не отпустить его в отпуск. Идея групп как раз в том, чтобы этот крутой, прокачанный человек свои знания раздавал. Не всем вообще, не всей команде – это нереально, а тем, с кем ему комфортно, и тем, кому эта тема интересна. Это довольно добровольное дело. Я инициирую процесс, но не назначаю эти группы. Люди решают сами, кто с кем.

Вопрос из зала: Спасибо.

Вопрос из зала: Галина Щукина, город Иваново, компания «Мобильный офис». После вашего интереснейшего доклада возникает ощущение, что все-таки 90% времени вы пребываете в состоянии стресса. Вопрос: ведется ли в вашей компании хронометраж выполнения задач? Как вам удается так прекрасно выглядеть?

Евгения Фирсова: Большое спасибо за последний вопрос. Я, конечно, не буду на него отвечать. 

Что касается хронометража. Я как раз час назад слушала доклад про JIRA. Мы используем JIRA и фиксируем трудозатраты, но только на задачи (у нас в разработке), которые связаны собственно с разработкой. Если на верстку какой-то задачи уходит какое-то время, оно будет учтено в JIRA, в отчетах, где угодно. 

Все, что касается обязанностей тимлида пойти на собеседование или прочитать постановку, задать по ней вопросы – такого рода деятельность мы не учитываем. Просто нет пока потребности. Мы отвечаем на тот вопрос, который нам задали. Нам задали вопрос: сколько стоит разработка. Разработка – когда мы начали пилить и до момента релиза. На этот вопрос мы отвечаем. 

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

Спасибо большое.

 

Завершение презентации 

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Артём Гавриченков

Артём Гавриченков

Ведущий разработчик в компании "Highload Lab".

В докладе описаны типичные ошибки программирования при написании серверных приложений на основе TCP-сокетов.

Эмин Алиев

Эмин Алиев

Генеральный директор ведущего итальянского агентства интерактивного маркетинга Buongiorno RUS LLC, ранее — исполнительный директор Mindshare Interaction.

Мир Digital-Агентства полного цикла с точки зрения менеджера проектов.

Сергей Скворцов

Сергей Скворцов

Исполнительный директор Openstat, FreeBSD committer, Perl adept и прочая, прочая...

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