пятница, 20 августа 2010 г.

Peopleware - управление проектами

Почитал классическую книжку из тех, которые пришли к нам из 80х об управлении проектами.

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

Моменты которые меня зацепили - касающиеся управления проектами.

Управление проектами

  1. Ошибки и люди, которые их совершают. И отношение к ним. Если в команде за ошибки сурово наказывают, возникает достаточно тяжелая атмосфера. Люди будут занимать оборонительную позицию в контексте рисков и инициатив. Идея в том, чтобы минимизировать вред который ошибка причиняет и максимизировать опыт который из нее извлекается. В такой среде каждая ошибка - это практически вклад в успех.
  2. Управление людьми - не пытаться сделать их одинаковыми и взаимозаменяемыми в производственном процессе (как на заводе), а уметь использовать их уникальность. Очень тонкий момент. Насколько часто хочется "сделать всех взаимозаменяемыми" настолько же часто хочется чтобы "каждый имел свою специализацию". Тонкий и холиварный момент...
  3. Отношение к качеству. Профессионализм программиста не позволяет сдавать продукт с низким качеством. С другой стороны, на идеальное качество уйдет бесконечно большое время. Продавливание сдачи продукта с качеством, которое не удовлетворяет программиста обычно отражается на его самооценке и мотивации. Тонкий момент... С другой стороны, те кто готов в конечном итоге платить за качество большую цену, для них оно  в конечном итоге ничего не стоит.
  4. Давление начальства на ход выполнения проекта. Оказывается "проекты в которых шеф не оказывал временного давления вообще ("Разбудите меня когда будет готово"), характеризовались самой высокой производительностью". Например с этим у нас сейчас тяжело. Каждый день разработчика кто-нибудь да спросит (причем в синхронном режиме по телефону / мессенджеру / лично): "Как там у нас дела? Как сроки?" Думаю давление можно и нужно сводить к минимуму путем асинхронной отчетности (как я её называю) - например через JIRA.
  5. Производительность разработчиков и факторы которые на ее влияют. Оказывается, язык значения не имеет (опыт 84-85 годов). Склонен согласиться с этим. Не думаю, что ОО-дизайн программы на Java будет как-то отличатся по времени от С++. При условии достаточного профессионала с обеих сторон. Также не имеет значения опыт, в определенных границах (от 2х до 10 лет). И, главное, зарплата - лучшие получали всего на 9% больше худших (при двукратно лучших результатов). Теперь финансовое  стремление нанимать звезд.
  6. Эффект Готорна. "Люди работают лучше когда пробуют что-то новое". Подписываюсь 
  7. Отличная мысль по поводу экспериментов и пилотов: Не экспериментируйте более чем с одним технологическим аспектом в пределах одного пилотного проекта.

Продолжение следует...


воскресенье, 15 августа 2010 г.

Проактивность

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

А. и Б. Стругацкие. Сценарий к к/ф "Сталкер"

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

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

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

  • рефакторить, то что его давно раздражало 
  • сочинять новый фрэймворк
  • писать все "с нуля", чтобы когда-нибудь в один прекрасный момент это выпустить
  • прикручивать новомодную технологию / фреймворк, которую так давно хотелось попробовать
  • бросаться в неопределенные академические изыскания

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

А теперь представим что в одной команде оказалось больше одного такого "проактиватора". Если в команде / продукте есть определенные проблемы, наверняка оба заметят их и начнут решать. Параллельно. Причем, наверняка разными способами.

Приходим к выводу что "проактивные" в том смысле в каком описано выше, это "неэффективные". Потому что упущен главный момент - коммуникация.

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

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

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

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

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

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

Будьте проактивны - это интересно