Иван Сагалаев: «Советы программиста по руководству программистами» | Конференция

10 декабря, в 16:00 прошла конференция: Советы программиста по руководству программистами http://conf.404fest.ru

На вопросы наших пользователей отвечал Иван Сагалаев, руководитель группы разработки контент-сервисов в компании «Яндекс». Еще Иван ведет блог о программировании, веб-разработке, проектировании. Особо тепло относится к темам OpenId, о чем делал доклад у нас на 404fest 2009, и Django, о которых с удовольствием ответит на несколько вопросов.

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

Иван о конференции:

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

Александр Фитискин, организатор конференции:: Очень интересные вопросы задавали Ивану, поэтому, без лишних слов, приступим.

Михаил Коробов: Какой, на Ваш взгляд, оптимальный размер команды для работы над проектом? Зависит ли он от объема работ и сложности? Если да, то не могли бы Вы привести примеры проектов, которые лучше делать одному, вдвоем, втроем, вчетвером, вдесятером?

Иван Сагалаев: Конечно зависит, как иначе? А также от сути работ, заказчика, скиллов участников команды, условий работы, времени года и ещё миллиона факторов. Размер команды -- лишь одна из переменных. И главное, оптимизация этой переменной не очень полезна. А часто и недоступна: у вас обычно по факту уже *есть* какая-то группа людей, которая берётся что-то делать, и с ними можно прикинуть, во что выльется этот процесс. А сколько там людей? Да какая разница...

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

Иван Сагалаев: Разделение сильно зависит от того, что люди умеют и хотят делать. Если один человек умеет верстать лучше двух других, то логично отдать ему всю вёрстку проекта. Если человек горит желанием реализовать какую-то фичу проекта от начала до конца, не надо ему мешать: например не давать тестировать код при наличии формального верстальщика. Фактически задача "главного" в том и заключается, чтобы смотреть и принимать решения, кого чем занять, прямо по ходу проекта.

Алексей Гусев: Здравствуйте, Иван. Во-первых, спасибо за ваш блог и форум. Очень полезные штуки. Во-вторых, вопрос. Я подписан на ваш твиттер, и все чаще и чаще там появляется то, чего раньше я за вами не замечал – раздражительность. Хоть и спокойная, но раздражительность. Она никогда не была направлена в мой адрес, но я немножко заметил. Мой вопрос – а вы ее замечаете? :-) Это доброжелательный вопрос, хотя может и не показаться таким. Спасибо вам за вашу работу.

Иван Сагалаев: Ну он на то и Твиттер ведь. Это то место, где я пишу "сырые" мысли, над обоснованием и эффектом от которых не думаю очень долго. Они подразумевают существенно меньшую личную ответственность, чем например то, что я пишу в блог. Поэтому они обречены быть существенно менее ровными и эмоциональными. Это хорошо :-)

Данил Мацынин: Какая структура команды, работающая над сервисом/продуктом тебе кажется более правильной и продуктивной и почему? Кому должны подчиняться разработчики и как они должны и должны ли контактировать с заказчиком? Кто назначает задачу разработчику - менеджер проекта или технический руководитель? Есть ли сроки выпуска проекта в Яндексе? Насколько они жесткие и как реагируешь на внезапные новости типа: "вот это все неправильно и надо переписать, мне нужно еще неделю или две"? Это непрофессионализм программиста? Я заметил в Яндексе у разных команд разные IDE и VCS, почему? На твой взгляд в команде должны быть одни инстументы разработки или разработчики вправе выбирать то что им по душе?

Иван Сагалаев: Много вопросов :-). Поэтому несколько кратких ответов на те, которые не нужно уточнять. Все участники проекта (разработчики тоже) должны подчиняться человеку, отвечающему за проект: это его рабочий инструмент. Человек, назначающий задачи -- это менеджер (это фактически определение менеджмента), и он обязан разбираться в предмете, иначе это не работает. Сроки выпуска есть, но берутся из очень разных мест (например: "новогодний проект надо выпустить к новому году" или "пока выходит, что мы закончим за 3 недели"). Никакие новости про проект не должны быть для менеджера внезапными, он должен быть в курсе проекта всегда; менеджеры, которые появляются раз в две недели с спрашивают "ну как у нас дела" -- это не менеджеры. Навязывать программистам какую-то одинаковые персональные инструменты просто странно, я не вижу ни грамма смысла в этом. Разные VCS -- в большой части эксперимент: может оказаться просто удобным, а может создать слишком много хаоса -- посмотрим.

Далер Фатыхов: Какой софт можете посоветовать для организации работы группы? Или же в этом вопросе обычно пишут под себя?

Иван Сагалаев: Три незаменимые вещи: багтракинг, wiki, vcs. Всё остальное можно пробовать по вкусу, наверное. Главное, чего мне не хватает сейчас -- это планировщика для планирования времени на задачи. Похоже придётся написать свой :-)

Александр Субботин: Здравствуйте, Иван! Есть ли в командах Яндекса контроль качества кода? Каким образом он осуществляется? Как вы считаете, творческий подход в работе программиста - это хорошо? Или программист должен делать, "как ему говорят"? Чем должен обладать программист, чтобы работать в яндексе?:)

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

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

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

Катюшка Герман-Евтушенко: Используются ли совещания/мозговые штурмы всей команды? Для каких задач?

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

Катюшка Герман-Евтушенко: Как проводится оценка сроков/стоимости проекта? Учитывается ли скорость работы отдельных программистов или берётся что-то "среднее"?

Иван Сагалаев: Снова как у Спольски. По крайней мере я пытаюсь всех в это "обратить". Вкратце -- все несделанные задачи детализируются до кусочков, занимающих несколько часов, и считаются в Excel'ной таблице. Каждый программист считается отдельно, и время на задачи ставит себе сам. К ним добавляется время на отладку, ожидание каких-то событий -- словом, всё, что занимает время. Исходя из этих цифр можно понимать, сколько займёт проект. Конечно не с точностью до дня. Но часто с точностью до недели. Что ГОРАЗДО точнее, чем обычные прикидки вида "2 месяца, а может год".

Катюшка Герман-Евтушенко: Какие члены проектной команды взаимодействуют с заказчиком? Кто это должен делать? Кто нет?

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

Катюшка Герман-Евтушенко: Как вводится новый сотрудник в команду? Практикуется ли наставничество? Каким образом?

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

Михаил Башкиров: Насколько остро стоит проблема поиска новых членов команды, которые будут работать с Python и Django?

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

Александр Киреев: Здравствуйте, Иван. Я недавний выпускник технического вуза. Меньше года я работаю в it-компании программистом. У меня вопрос, нужно ли стараться как то зарекомендовать себя перед начальником, перед тим-лидером, выступать с какими — то своими идеями и пожеланиями или достаточно тихонько сидеть и получать свой оклад, делать те задания, что поручены. Я думаю у вас был этап в жизни когда ваша карьера была в самом начале. Вот какие-то главные советы и принципы построения карьеры (не в плане технологий и языков и т.п., а в плане отношения к работе, задачам; самомотивации) можете дать? Для вас близкий к идеалу работник это кто? Какими навыками/качествами он должен обладать? И чем, скажем, вы руководствуетесь при выборе кандидатур себе в команду?

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

Антон Моськин: Тут уже был вопрос про карьеру. Я его немного дополню. Уверен вам, Иван, как и мне, довелось побывать и в роли простого специалиста в команде и в роли лидера. Соответственно в каждой из ролей было какое-то представление самого процесса с точки зрения эффективности и с точки зрения личностного и карьерного роста. А вопрос в том — есть ли существенный отличия и противоречия в этих представлениях? Особенно важны те моменты, которые оказались кардинально противоположными.

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

Алексей Абрамов: Приходилось ли в каких-то случаях прибегать к доводу «c'est la vie - я тут пока что начальник»? Было бы здорово услышать пару советов, как обходиться без этого. Спасибо.

Иван Сагалаев: Не приходилось. Не могу исключить такое средство, но "административный ресурс" аналогичен ядерной бомбе -- лучше не использовать никогда. Чтобы этого не было, надо заботиться заранее. Например ещё на собеседовании кроме технических вещей стоит попытаться понять, можно ли с человеком вообще договариваться. По ходу разработки проекта часто и много разговаривать с программистами о том, как они задумали сделать что-то, пусть даже на уровне идей, чтобы обсуждать потенциальные проблемы до того, как на них ушло много сил и эмоций. Дальше, если конфликтная ситуация создалась, ничто не поможет лучше спокойного аргументированного разъяснения: нам повезло, программисты обычно логику воспринимают лучше, чем политику. Ну а если совсем не получается убедить, но и не убедили вас, то неустраивающее решение стоит принимать не в форме "я сказал!" а в форме: "хорошо, мы не можем договориться, я понимаю, что возможно не прав, но просто для того, чтобы двигаться дальше, давай сделаем вот так под мою ответственность".

Сергей Тарковский: Иван, как бы вы реализовали слой Object Relation Mapping, если бы пришлось его делать с нуля?

Иван Сагалаев: Ну как...

class Query(object):
def __init__(self):
# ...

Ну и дальше уже очевидно! А если серьёзно, то хорошие ORM'ы уже есть. Писать свой с нуля надо только в каком-то очень специфичном случае, и ответ на вопрос "как" зависит как раз от этой специфики.

Максим Семехин: Привет. Как жить программисту после 30? Что делать, куда деваться, когда ты уже не такой умный и быстрый как в молодости?

Иван Сагалаев: Не, ну неправда, что после 30 вот так сразу все тормозить начинают :-). Есть и седовласые дядьки с очень ясной мыслью. Но вообще да, с годами концентрировать внимание сложнее, и мозг гибче не становится. Выход -- уходить в области, где опыт стоит выше, чем "raw power". Архитектура систем, управление людьми, наука. И ещё -- обучение следующих поколений.

Александр Фитискин:: Спасибо Ивану за интересные и подробные ответы. На этом очередная конференция заканчивается.