Archive for the ‘Менеджмент’ Category

По поводу self empowered team.

Пятница, Октябрь 22nd, 2010

Когда-то, порядка года назад я написал Манифест работодателя. Сегодня его понадобилось перечитать.

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

Собственно команда сильно отличается от других вот чем:
а) Костяк команды очень профессиональный. Умные, ответственные, активные, ищущие новые знаний люди с большим опытом. То, к чему я привык, это когда дай бог 10-20% таковы,
а остальные либо неопытны, либо не слишком мотивированны, либо малоактивны.
б) VP engineering’а похоже ставил цель сбор именно такой команды. И на данный момент он позволяет команде принимать множество достаточно важных решений, которые зачастую в других компаниях принимались бы им или кем-то из top management’а.
в) В момент набора новых людей идет тщательный отбор тех, кто по духу подходит в команду.

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

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

Втереть в голову, смыть, повторить.

Четверг, Сентябрь 30th, 2010

Есть у меня забавная, но, увы, абсолютно не осуществимая идея.

Представим себе, что у нас есть достаточно большой проект (ну скажем на 9 месяцев, на пару десятков человек). Такой, вполне настоящий проект.

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

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

Что мы делаем дальше, по окончанию проекта, это стираем все артефакты (код, документацию, баг треккер, систему контроля версий, whiteboard’ы). В общем стираем ВСЕ, кроме
памяти людей и заставляем их выполнить еще раз проект, снова записывая время. И это повторяется, пока числа не стабилизируются.

И вот, что мне было бы ОЧЕНЬ интересно поглядеть график. По вертикали — время потраченное на каждую часть, по горизонтали номер повторения. Что-то типа вот такого:

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

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

Политика закрытых дверей

Четверг, Август 5th, 2010

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

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

Фактически все остальное должно обсуждаться так, чтобы это не было секретом.

Почему не все оффшорят?

Среда, Август 4th, 2010

Когда-то Игорь Полоз написал комментарий:

«Теперь понятно, почему у нас в Харькове, да и в Украине вобщем, большинство девелоперских фирм имеют головной офис в США, скажем. Ибо разница в зп = 2к$ у нас и 6к$ там (для сеньора) достаточно велика, притом что качество кода не думаю, что сильно отличается. Как в рекламе: «Если нет разницы — то зачем платить больше?» 🙂 »

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

Ну, начнем с того, что есть то, что нельзя оффшорить — разные там правительственные контракты. Но, это естественно, не такая уж большая часть IT проектов.

А вот по остальным пунктам, таки пройдусь:

а) Езда по накатанной колее

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

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

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

б) Местные программисты быстрее реагируют на изменение направления.

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

в) Знание языка.

Когда оффшорный программист живет на остравах умпы-лумпы и изъясняется на очень ломанной версии английского и коммуницировать приходится только через менеджера/лида (в оффшорном офисе), у которого с английским получше, но, тем не менее, все равно ломанный, то становится достаточно сложно проверить уровень понимания того, что нужно сделать.

г) Бухгалтерия

Само собой, платить только местным гораздо проще, чем платить и местным и не местным (особенно если за рубежом именно полноценный офис).

д) Иллюзия контроля

Часто менеджер должен видеть, что программист с напряженным видом сидит с 9 утра до 6 вечера, чтобы чувствовать, что программист трудится . А когда кто-то на другом континенте приходит и уходит неизвестно когда, то возникает вопрос о контроле.

Сразу скажу, что чувство контроля тут абсолютно иллюзорно, но тем не менее куча менеджеров очень полагаются именно на иллюзорность.

е) Решение проблем заказчиков.

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

ж) Боязнь кражи интеллектуальной собственности

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