8 posts tagged

управление

Как я диагностирую проекты, когда они болеют

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

Don`t panic

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

Команда

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

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

Проектные решения

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

Под такими решениями я понимаю, например, текущую архитектуру сервиса. Опору на внешние источники или зависимости. Договоренности о взаимодействии частей системы друг с другом, API, SOAP и т.д.

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

Процессы

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

Задача

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

Риски

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

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

Итоги

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

Если проект небольшой, например, не более 10 человек готовили проект около полугода. То такой анализ можно сделать в одиночку за одну-две недели. С минимальным отрывом текущей команды о работы. Ну а дальше уже принимать управленческие решения.

 No comments    17   Dec 21   кода кода   управление

Парадоксально, но добавив еще пару разработчиков, вы не разгрузите команду

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

Краткосрочная перспектива

Новые люди в проекте затормозят его, а не ускорят. Есть даже шутка: что 2 программиста сделают за 2 дня, то 4 программиста сделают за 4 дня.

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

Во-вторых, мы увеличиваем количество связей между людьми. Напомню, что оно растет экспоненциально. Для команды из 5 человек – 10 попарных связей, а для 7 уже 21 связь. Команде нужно общаться. Если вы думаете, что у вас схема «звезда», когда каждый разработчик взаимодействует только с PM-ом, то, скорее всего, вы ошибаетесь. В сложных, не детерминированных изначально системах, где в процессе работы принимаются проектные решения, попарное взаимодействие необходимо.

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

Среднесрочная перспектива

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

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

Долгосрочная перспектива

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

Что же, выхода нет?

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

Но ведь как-то команды растут?

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

 No comments    15   Dec 21   кода кода   управление

Еще немного о удаленной работе

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

Вот приходит сотрудник и говорит: «Ребята, хватит жить в прошлом веке. Есть скайп, почта и телефон. Я могу брать задачи и выдавать результат, зачем мне каждый день терять два часа в пробках?» Решили попробовать. Договорились, что пока не каждый день, но некоторые дни работать удаленно.

И вот первый же «тестовый» день. Мелкий вопрос мы обсуждали письменно в скайпе полтора часа (с перерывами на 3-5 минут), тогда, как очно ушла бы пара минут. Просьбу «сделать более подробное описание» в одной из задач нашего таск-менеджера сотрудник выполнить не смог, так как был страшно занят. Отчет, о котором мы договаривались так же подготовить не успел. А на следующий день пришлось потратить еще час, что бы узнать, чем занимался сотрудник. Выяснилось, что не тем.

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

Вы скажете, что я сам дурак. Ну зачем было переписываться полтора часа, когда можно позвонить? Да по тому, что сразу это не очевидно. Я не думал, что маленькая сложность может вызвать такие затруднения. Да и неправильно понятая фраза завела разговор в тупик дважды.

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

При этом, у нас есть другой сотрудник, который успешно работает из другого города. и проблем не возникало ни разу. В чем секрет?

 90 comments   2016   мысли   управление

Как мы вводили git

Git — это одна из популярных систем контроля версий. Код — это, прежде всего, текст. Такой текст, который правят многократно и по чуть-чуть в разных местах. Хранить только последнюю версию кода не дальновидно, по тому, что часто какие-то правки приходится отменять, а в каких-то случаях надо посмотреть «как оно работало раньше». Хранить каждую новую версию кода, то есть копировать всю директорию, допустим раз в день, не удобно по двум причинам: во-первых, занимает много места, а во-вторых, не дает никакого понимания о том, что именно изменилось.
Умные программисты придумали решение этих проблем. Оно заключается в том, что бы хранить какую-то базовую версию, а после сохранять только маску изменений. Например, мы храним 1000 строк кода и после изменений запоминаем, что поменялись 387 строка и 425.
Такое решение дало еще один неожиданный плюс. Оно позволило работать над одним и тем же кодом разным людям одновременно. Первый программист поменял вторую, третью и четвертую строку, а второй — девятую и десятую. Система сама поняла, что может применить к начальному коду и те изменения и эти. И только, если возникнет конфликт, придется разруливать людям.

Америка

Впрочем, если вы так или иначе связаны с разработкой программного обеспечения, скорее всего, Америку я вам не открыл. Во всем мире различные системы контроля версий — неотъемлемый атрибут любого программиста. Читая профессиональные форумы, блоги известных web-разработчиков и доклады с различных конференций сложно себе представить, что кто-то может жить без git-а или svn-а. Однако, в наших реалиях куча небольших веб студий и одиночек-фрилансеров работают «по-старинке». Так получилось, что и я на первых своих местах работы с системами контроля версий познакомился только заочно. До сих пор стыдно признаться, что несколько лет я писал код без таких систем.
Впрочем, я был такой не один. И так получилось, что у нас собралась команда из четырех человек, где никто полноценно с контролем версий не работал. У меня был до этого опыт, где все настроили до меня и оставалось только коммитить, то есть записывать изменения которые я внес. Еще у двоих членов команды был подобный опыт. Однако никто из нас не представлял, как полностью должна работать система от компьютера программиста до «боевого сервера».

Как ни странно, гугление не могло ответить на те вопросы, которые возникали у меня в первую очередь. Например гугл на вопрос «Как смержить ветки git» дает около 700 результатов и вся первая страница по делу. А на запрос «git локально или на сервере» дает 275 тыс ответов и я не смог найти что-то в тему.

Наши правила

Многое мне было непонятно. Но в итоге чтения кучи статей и советов я принял ряд решений.

  1. Мы отказались от гита локально на каждом компьютере разработчика. Вместо этого, мы используем IDE и копию проекта на нашем сервере. У каждого разработчика есть своя локальная копия и своя удаленная копия. Уже на сервере стоит гит и туда надо зайти что бы провести с ним какие-то операции. Такое решение я принял по целому ряду причин. Основная причина в том, что мы взяли курс на проекты выше среднего по сложности и настраивать у каждого разработчика веб-сервер с нужными пакетами в условиях разных ОС и различной удаленности друг от друга сложная задача. А внедрить все это надо было без ущерба для производства.
  2. Никаких встроенных в IDE систем поддержки git и других «улучшителей вкуса» мы решили не использовать. Во-первых, в нативных командах из консоли нет ничего, чему нельзя научить за пару дней. А во-вторых, меня однажды такая система поддержки сильно подвела — вывела совсем не то, что произошло на самом деле.
  3. Мы ввели правило одна задача — одна ветка. Коммитов в нее может быть много, но чаще 1-2. Сливаем изменения только после завершения задачи.
  4. Все, что не касается напрямую нашего кода мы стараемся исключить из системы контроля версий. С этой задачей до сих пор справляемся хуже всего.
  5. Ввели правило «сервера для тестирования». Каждый раз после сливания изменений от разных разработчиков сайт поступает на тестирование и только потом выходит в продакшн, как бы не торопил заказчик.
  6. Мы стали использовать git в связке с Bitbucket. Система контроля версий без удаленного репозитория и в половину не так хороша. Но это, наверное, тема для отдельной заметки.

И все пошло, как по маслу?

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

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

А какую систему контроля версий используйте вы? И какие сложности были с её внедрением?

 2 comments   2016   web   программирование   управление

Книги о самых посещаемых сайтах в рунете

На Новый год мне подарили две книги: Яндекс.Книга и Код Дурова. До того, как я их открыл и прочитал для меня между ними было много общего. Сегодня будет экспериментальный пост-рецензия.

Яндекс.Книга

В каждом, самом незначительном, аспекте книги, от обложки до верстки, от структуры повествования до построения фраз чувствуется, что автор проникся особым духом компании Яндекс. Книга рассказывает о том, что наш поисковик №1 совсем не калька с Гугла, и заставляет поверить, что где-то на постсоветском пространстве остались еще светлые головы.
После прочтения я для себя вынес, что

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

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

Стоит прочесть всем, кто ведет бизнес в России; всем, кто хоть отдаленно связан с IT; всем, кто управляет хотя бы маленькой командой; всем, у кого есть конкуренты; всем кому интересно, что у нас все еще есть чем удивить запад.
Не стоит читать только если вы не верите в людей, в страну, в идеи и ненавидите все это.

Код Дурова

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

  1. Адекватные деловые решения не нужны. Стартап вырастет сам, если ты гений.
  2. Когда тебе хочется без причин плевать на пользователей ты можешь это делать. А когда на тебя будут давить сверху ты можешь просто показывать фак и говорить, что пользователи не поймут, если ты закроешь группу Навального.
  3. Если у тебя проблемы, просто психуй, бросай компанию и берись за разработки совершенно в другой области, по тому что ты гений и новый стартап взлетит так же, как и старый.

Стоит прочесть тем, кто в восторге от «Вконтакте» и считает его скорее божественным провидением, чем земным созданием.
Не стоит читать если вы верите в здравый смысл в бизнесе.

 1 comment   2016   мысли   управление
Earlier Ctrl + ↓