Project closed. Lessons learned.

Рубрика: Development, Just a life, Работа | 11 March 2009, 11:26 | juriy

Вот и подошел к концу очередной абзац моего резюме. Проект, которым я руководил последние полтора года, закончен. Как минимум, закончена его разработка с нашей, аутсорсинговой стороны.

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

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

Второй урок.
Ради спортивного интереса, этот будет из области позитивного опыта. Обычно такие заметки как эта, это заметки-страшилки в духе “как я наколол дров”. Поступлю иначе: разбавлю post mortem историями успеха.

Standup meeting в команде. Мало кто будет спорить с полезностью этого явления: каждый член команды рассказывает про то, что он успел сделать, какие у него планы и что мешает работать (да, да, это из Scrum). Я добавил в утренние встречи небольшую “зарядку для хвоста”: после встречи мы с командой рассматривали небольшую задачку на знание Java. Я выбирал задачки из Java Puzzlers иногда из своего опыта, иногда подсказывали друзья или коллеги. Задачки были простыми и покрывали один-два аспекта языка.
Эффект был самым положительным: во-первых, встречи перестали быть уж слишком формальным “рапортованием о сделанной работе”. Во-вторых, задачки ненавязчиво стимулировали глубже познакомиться с предметом: я неоднократно замечал, как мои коллеги читали материалы, чтобы детальнее разобрать механизмы, которые затрагивала задачка. В-третьих, задачки настраивали на “рабочую волну”: после митинга было настроение поработать и закончить свою задачу, а не почитать еще немного “корреспондент”.

Третий урок.
Тут даже не урок, а case-study. Кейс такой: человек регулярно заваливает интеграцию, забывает залить нужные файлы в репозиторий или заливает промежуточные варианты, вместо нужных. После того, как это обнаруживается, тратит некоторое время и все-таки чинит сборку. Проблема оказалась в том, что у сотрудника не был настроен плагин для работы с системой контроля версий.
Мораль: если симптом повторяется, не стоит закрывать на него глаза, даже если его легко вылечить. Порой вылечить причину еще проще. Вторая мораль: не все разработчики одинаково легко озвучивают свои проблемы на утренних встречах, даже если проблема совсем мелкая (“ребят, у меня слетел плагин, помогите, пожалуйста, его настроить” – нежелание сказать эту простую фразу портило человеку жизнь несколько месяцев).
Конечно, это раздолбайство разработчика. Но задача team-lead’а такие раздолбайства находить и пресекать.

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

Вот, вобщем-то и все. Теперь осталось только выставить пивка коллегам да аккуратно сложить бумаги перед переездом на новый проект (а может, и на новое место работы). Удачи вам в ваших проектах.

Комментариев: 11

11 Responses to “Project closed. Lessons learned.”

Сюда ссылаются:

Комментарии:

  1. Smudgy

    Поздравляю с успешным(?) окончанием проекта. Надеюсь что новый финансовый год принесет новые интересные проекты.

    По поводу третьего пункта и контроля версий могу сказать одно. Такое большое разнообразие программ в винде которые работают с репозиториями – это большое зло, т.к. каждый делает коммит по-своему, иногда некорректно. Поэтому хочу предложить + к твоему Case-study: Провести тренинг/обсуждение по поводу наиболее приемлемого для всех клиента, потом установить и настроить его у _всех_ членов команды перед стартом разработки.

  2. juriy

    Успешное, успешное. Куда же оно денется, успешное окончание-то :-))

    К третьему кейсу, у нас все так и было. Тут на блоге где-то даже валяется моя версия “вводного курса в Perforce”.

    Мы использовали плагин к Idea + командную строку.

  3. Smudgy

    про Perforce отдельный разговор…

  4. juriy

    Не надо, там уже спама и так хватает: http://voituk.kiev.ua/2008/02/14/quick-perforce-guide/#comments

  5. Ad_Astra

    ой, насчёт фидбэка – есть такая тема, ага. Тоже недавно делала один проект… и только залив его на production-сервер заказчика, я вдруг от него узнала, что там ВООБЩЕ всё не то, и переделывать надо едва ни с нуля – в итоге, жертвуя своим сном и здоровьем (под конец меня стало натурально тошнить от кофе и лимонника), я таки это сделала, и даже сроков не сорвала. Но вопрос “да где ж ты, [beep], дальше-то был, [beeeeeeeeeeep] твою налево?” преследовал меня постоянно. Даже если я скосячила и не сразу поняла, что от меня требуется – это надо постоянно отслеживать и в случае чего говорить, что не устраивает и где доделать. Ибо сделать нормально сразу куда проще, чем переделывать :)

  6. COTOHA

    stand-up с задачками это прикольно.

    а все велись и решали? я просто всё порываюсь девам дать простую задачку, но реагируют единицы, а остальные просто сидят со словами “работать надо, а не в игрушки играться”.

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

  7. juriy

    Вобщем, да, все велись. Народу даже нравилось.

    Правила такие были. Сначала минуты 3-5 на обдумывание, потом каждый по очереди говорит свой ответ (первым каждый день говорит следующий человек). Потом описание правильного ответа и короткий бриф (если нужно), почему все работает именно так.

    Потом, время от времени, флейм на тему “почему правильно должно быть так как у меня, а не так как в книге” :-)

  8. COTOHA

    в принципе, в такой постановке вопроса им деваться было некуда :)

    надо и себе всех строить и не отпускать пока не решат… гы-гы

  9. rssh

    Да, этап.
    Ну что-ж, пусть следующий проект будет интересным как по деньгам так и по задачам ;)

  10. cаша

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

Leave a Reply