Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

Люди как наиболее важные компоненты процесса разработки ПО

Alistair Cockburn - это один из моих любимейших авторов в области управления процессом разработки программного обеспечения, а его статья "Characterizing people as non-linear, first-order components in software development" - несомненная жемчужина в сокровищнице мирового достояния по этому вопросу (русский перевод статьи доступен здесь). Автор, эксперт в области методологий разработки ПО, более 20 лет посвятивший изучению этого вопроса, пришёл к выводу, что на пути любой методологии стоит 2 основных проблемы: Людям, занятым в проекте, как правило совершенно неинтересно изучать новую методику. Они вполне могут обойтись и без методологов, и при этом успешно создавать программное обеспечение. Проанализировав около сорока проектов из своей практики, автор сделал следующие важные выводы: Практически любую методологию можно с успехом применять в каком-нибудь проекте. Любая методология может привести к провалу проекта. Тяжеловесные методологии тоже могут успешно применяться в работе. Облегченные методологии чаще приводят к успеху, и, что более важно, разработчики сами говорят, что успех проекта был обеспечен именно методологией. Я не нашел ни одной теории, которая объяснила бы, почему облегченные методологии (те, в которых мало места уделяется всяческим формальностям), чаще приводят к успешному завершению проекта, нежели тяжелые методологии, где формальности играют очень большую роль. И тут я наконец-то понял, что прямо перед нами всегда находится нечто, чего мы не замечаем: люди. Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте. Теперь я рассматриваю все в обратном порядке - сначала люди, а потом методология, как второстепенный показатель. Какие же человеческие качества делают людей одновременно и столь важной, и столь непредсказуемой компонентой процесса разработки? Автор выделяет следующие: Человек - существо, которому необходимо общение. Причем общаться он предпочитает в режиме непосредственного диалога, лично, по типу "вопрос-ответ". Человеку трудно постоянно работать сверхурочно. Человек - существо изменчивое, он меняется в зависимости и от времени, и от пространства. Как правило, у человека есть чувство гражданского долга, он может хорошо ориентироваться в ситуации, брать инициативу в свои руки и делать "все, что необходимо" для того, чтобы проект завершился успешно. Человеку нужно время, как на размышление, так и на общение. Человек хорошо работает, опираясь на примеры. Человек предпочитает скорее потерпеть неудачу из-за своего консерватизма, нежели рискнуть, но сделать что-то необычным образом; ему больше нравиться изобретать, а не находить готовые решения, он может одновременно держать в голове совсем немного сведений, он делает ошибки и с трудом меняет привычки. Отдельная личность может легко возобладать над проектом. Способность человека выполнять те или иные задания в большей степени определяется его личными качествами. Когда я провожу опрос по какому-нибудь проекту, я всегда спрашиваю людей, что, по их мнению, привело к конечному успеху работы. Чаще всего я получаю один и тот же ответ: "В ключевой момент разработки несколько человек взяли на себя инициативу и сделали все от них зависящее, чтобы выполнить проект". Приведу ещё парочку важных на мой взгляд заключений, изложенных автором в статье:   - Я прихожу к заключению, что большинство проектов вполне можно вести, руководствуясь (верными) не очень точными описаниями: не очень точную документацию по проекту легче читать, приводить в порядок и обсуждать. Архитектуру системы, изображенную с невысокой степенью точности, легче запомнить; в таблицах с не очень точно описанными требованиями легче расставлять приоритеты и легче оценивать масштабы сделанной работы на ранних стадиях проекта. Выполненная не очень точно проектная документация лучше передает "идею" проекта, после чего читатель может начать "ориентироваться в ситуации".  - Вариации поведения культур методологу учитывать еще труднее, чем вариации каждодневного поведения отдельных индивидуумов. На сегодняшний день я не знаю ни одной методологии, при создании которой принимались бы во внимание культурные особенности (моя методология - не исключение). Впрочем, я знаю людей, которые учитывают местные культурные особенности при формулировании методологических рекомендаций. Конечно, я нисколько не тешу себя мыслью, что смог в этом коротком посте передать всю глубину и ценность изложеных в статье идей, однако надеюсь, что убедил многих в том, что статья достойна быть прочитанной.

Posted by Vitalii Tsybulnyk on Thursday, July 9, 2009 8:29 AM
Permalink | Comments (1) | Post RSSRSS comment feed

О лапше в Software Development'е

На написание этой заметки меня вдохновило известное философское эссе Harry Frankfurt'а 'On Bullshit'. На самом деле это эссе не имеет никакого отношения к разработке ПО, однако, как и любая философская теория, оно имеет оношение ко всему. На русский язык я бы лично перевёл название как "О лапше" в том смысле, что современное общество просто-таки захлёбывается в лапше, которую люди постоянно вешают на уши друг другу. Зачастую это преподносится и интерпретируется не как явная вопиющая ложь, а скорее как хитрость, некоторое привирание, без которого якобы никак не выжить и не пробиться. Давайте пронаблюдаем это на примере процесса разработки ПО.  Начнём с первого контакта заказчика и испольнителя. Ставлю десять к одному, что каждый из них сознательно себя презентует лучше чем он есть. Т.е. заказчик наверняка привирает о своей солидности и стабильности. Но это ещё цветочки по сравнению с тем, какие, мягко говоря, преувеличения можно иногда услышать от компаний-исполнителей. Яркие примеры из моей практики: - У нас команда из 20 разработчиков (реально 4) - Мы профессионально владеем следующими технологиями ... (реально специалистов по половине из них нет на данный момент совсем, их наймут только если проект стартует, а в другой половине большинство персонала - новички) - У нас работают специалисты со стажем от 7 до 15 лет (реально от 0 до 6) Предположим, первая лапша успешно развешена и процесс переходит на стадию обсуждения условий сотрудничества. Здесь очковтирательство идёт по нарастающей: - Мы сделаем этот проект за N недель (реально все знают, что не быстрее, чем 2xN + M) - ответная лапша заказчика: мне этот проект нужен в мае, крайний срок в июне  (реально в сентябре, но может и годик подождать) - ещё один сногсшибательный трюк, который глава одной софтверной компании , где мне приходилось работать, неоднократно проворачивал с потенциальными заказчиками: "а у нас такая функциональность уже есть готовая!" (а реально, если заказчик "повёлся", то на написание этой "готовой" функциональности абсолютно с нуля и в нереальные сроки будет срочно выделена штурмовая команда, которая в лучшем случае даст эту функциональность через месяц) Однако все эти хитрости просто детские игры по сравнению с тем, какую лапшу вешают на уши друг другу компания и нанимаемый сотрудник, руководитель и подчинённый: - вы возглавите команду / будете руководить / займёте позицию ведущего ... и т.п. (не поверите, я знаю команду, в которой из 5 разработчиков 4-х брали на позицию тим-лидера ) - зарплата у нас не такая большая, но в конце проекта будет солидный бонус (либо не будет совсем, либо будет, но совсем не солидный) - сначала будет пару месяцев сопровождение старого проекта, потом начнём новый (скорее через пару лет) - мы собираемся переехать на новый оффис, ввести страховки сотрудникам, обновить технику и т.п. (конечно собираетесь... собираться - это не дорого) и т.п. (про поведение работников я совсем умолчал, иначе пост мог бы превратиться в целую книгу) Естественно, вся эта лапша имеет под собой реальные и вполне понятные основания: когда очень хочется что-то сделать, а это не получается, "приходится" идти на уловки, чтобы добиться желаемого. Но кроме этого, я неоднократно замечал, что некоторые считают такое очковтирательство нужным всегда, даже если в этом нет большой необходимости или явной выгоды. И более того, некоторые даже осуждают честность и открытость как признак слабости или неопытности. А есть люди, которым просто очень нравится дурить других людей.

Categories: Management
Posted by Vitalii Tsybulnyk on Thursday, June 18, 2009 2:16 PM
Permalink | Comments (10) | Post RSSRSS comment feed

Как удерживать программистов

Это последний пост из серии постов по книге Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. И вопрос в нём поднимается, пожалуй, самый сложный. Итак, вы успешно наняли подходящих людей и сфоримировали настоящую команду. К сожалению, на этом всё только начинается. Как сохранить эти непростые достижения подольше? Как удержать программистов от ухода? Я уже написал об этом несколько постов, раскрыв некоторые моменты: мотивация, антипаттерны руководства и сбаллансированные отношения руководитель-подчинённый. Однако ввиду важности, сложности и неоднозначности вопроса, хочется процитировать ещё несколько интересных моментов, касающихся аттестации и зарплаты: • Не думайте, что, наняв сотрудника, вы заключили с ним договор раз и не всегда. Вы должны нанимать сотрудника постоянно. Успешно работая в своей области, сотрудник приобретает новые знания и опыт, следовательно, стоимость его услуг растет. Поэтому его необходимо перекупать, пока это не сделали конкуренты, если, конечно, вы не стремитесь стать для них «кузницей кадров». • Пересмотр договора о найме, «по договоренности», без прозрачной процедуры дезориентирует и демотивирует сотрудников. В силу своей интроверсии, программист, как правило, предпочтет найти повышение зарплаты в другой компании вместо того, чтобы просить об этом свое начальство. Поэтому, настоятельно рекомендую, проводите периодический пересмотр условий договора - аттестацию. • Кто оценивает? В первую очередь, руководство: линейный руководитель и менеджеры проектов, в которых участвовал данный сотрудник. Однако, не менее важны экспертные оценки, которые ставят люди, взаимодействующие с этим сотрудником на разных уровнях, коллеги, смежники, подчиненные, клиенты. В западной литературе этот подход называется оценка по методу «360 градусов» • Еще один важный и необходимый результат аттестации – план развития, - какую новую ступень карьерной лестницы будет достигать сотрудник и что ему необходимо сделать, чтобы на нее перейти. Что изучить и освоить: новые технологии (согласуем с личными целями и стратегическими потребностями компании), смежные специальности (снижаем риск в случае увольнения коллеги). Каких результатов добиться. Поставленные цели должны соответствовать широко известному в западном менеджменте критерию SMART, представляющему собой аббревиатуру из пяти английских слов: Specific (конкретный), Measurable (измеримый), Achievable (достижимый), Relevant (сопоставимый) и Timebound (определенный во времени). • При решении вопроса "Сколько надо платить программисту?" необходимо помнить, что участник команды это не «винтик», как думают некоторые CEO, который можно легко заменить, купив на рынке аналогичный. Я не утверждаю, что программисты незаменимы. Заменимы и еще как. На сегодняшний день средняя текучесть кадров в ИТ составляет по моим оценкам 20-30% в год, однако, отрасль не только не рухнула, но и успешно развивается. • Как правило рыночная «вилка» вознаграждения для данной квалификации известна, допустим от X до 1.5*X. Можно рискнуть и платить по нижней планке X. Однако, возможность получать в 1.5 раза больше за ту же работу, скорее всего перевесит все остальные стимулы, для удержания специалиста в данной компании. Эта ситуация усугубляется еще и тем, что «охотники за головами» делают разрыв в вилке еще больше, чтобы побыстрее перекупить квалифицированные кадры. Далее в книге идёт очень скурпулёзный рассчёт стоимости замены уволившегося сотрудника. Итоги этого рассчёта впечатляют: даже не учитывая затрат на оплату услуг рекрутеров (которые до недавнего времени стоили весьма немалых денег) для компании с доходностью 25% "мгновенная" замена специалиста с зарплатой $2000 может стоить до $27,000. В статье берётся "время адаптации" равным 6 месяцев, но даже если принять более реалистичные для нашего аутсорса 2-3 месяцев и компанию с меньшими накладными расходами, то всё равно затраты на замену специалиста составят не менее полугодовой зарплаты этому сотруднику, что совсем не легко понять "интуитивно". Какой отсюда следует вывод - каждый может решить для себя сам, однако даже просто обладание такой информацией, на мой взгляд, может повлиять на отношение к этому вопросу.

Posted by Vitalii Tsybulnyk on Tuesday, June 16, 2009 7:29 AM
Permalink | Comments (3) | Post RSSRSS comment feed

Как принимать собеседование у программистов

Это ещё один пост из серии наиболее интересных для меня глав книги Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. Сегодня замечательная тема, одна из моих самых любимых. Эта тема интересна и полезна не только тем кто принимает или собирается принимать собеседованя у кандидатов и хочет отточить свой подход к этоми непростому делу. Эта тема полезна всем без исключения участникам трудового процесса, т.к. позволяет не только научиться успешному прохождению собеседования, но и научиться принимать собеседование у компании, научиться делать верные выводы не только о том, касколько вы подходите компании, но и насколько компания подходит вам. Привожу здесь наиболее понравившиеся мне моменты, но если тема интересна вам, лучше прочитайте саму книгу • Необходимо помнить, что мотивация разработчиков ПО начинается с приема на работу. В старой экономике людей нанимали за умения и обучали нужному отношению к делу. В новой экономике необходимо поступать с точностью до наоборот: нанимать за нужное отношение к делу и учить необходимым умениям. • В настоящее время нет каких-либо достоверных формальных методик определения квалификации программиста. Мой опыт показывает достаточно значимую корреляцию хороших способностей к программированию и сверхвысокого значения IQ . Высокий балл диплома и престижное математическое или техническое образование свидетельствует об общих способностях кандидата успешно осваивать новый материал. Диплом о престижном высшем образовании немаловажен для хорошего программиста, хотя и не является необходимым условием. • Отдельно остановлюсь на тестах и практических заданиях по специальности. Относительно их необходимости у меня имеются большие сомнения. Как правило, технические тесты ориентированы на проверку узкоспециальных знаний: структур данных, алгоритмов, конкретных стандартов и API, и т.д. Правильный/неправильный ответ на вопрос: «i=1; i = i++ + ++i; чему равно i?», - мало о чем свидетельствует. Попытки давать кандидатам олимпиадные задачки по программированию, или задачки из книжки «Математические головоломки», у меня, как правило, ассоциируются со стремлением, возможно, не очень успешных вчерашних студентов к самоутверждению или с желанием продемонстрировать кандидату его несостоятельность, чтобы затем снизить предложение по зарплате. Я применял тесты по специальности - несколько десятков простых вопросов на 15-20 минут по базовым понятиям стека технологий таких, которые просто невозможно не знать, если ты имеешь практический опыт в данной области. Результаты этого теста использовались только для того, чтобы выяснить, в какой области кандидат более уверенно ориентируется и адекватнее позиционировать его среди имеющихся направлений разработки. • Технические тесты могут продемонстрировать уровень IQ и эффективность левого полушария, возможности которого подтверждены, как правило, дипломом о высшем образовании и всем успешным опытом предыдущей работы. Часто при обсуждении данного тезиса меня спрашивали: «А вдруг кандидат наврал о прошлом опыте?» На мой взгляд, одного двух вопросов с просьбой уточнить некоторые конкретные технические детали достаточно, чтобы рассеять или подтвердить подобные сомнения. И еще, если вы не в состоянии распознать то, что человек выдает себя не за того, кто он есть на самом деле, возможно, вам еще рано руководить людьми. • Креативность и эффективность человека в командной разработке зависят в первую очередь от уровня его эмоционального интеллекта, EQ и деятельности правого полушария: целеустремленность, воля, эмпатия, интуиция, способность к эвристическим суждениям. Я, к сожалению, пока не встретил достоверных тестов правого полушария. Поэтому слушаем, слушаем и еще раз слушаем. А главное слышим! При отборе кандидатов только очное интервью «глаза в глаза» и личный опыт работы с людьми позволят вам создать эффективную программистскую команду. • При проведении технического интервью следует придерживаться следующих основополагающих принципов: - Помните, вы ведете переговоры с потенциальным партнером по бизнесу, а не пытаетесь «купить на рынке товар подешевле». - Каждый человек уникален и ему присуща своя ценность. Если вам нечего предложить кандидату, то это не значит, что он «лузер». - Имейте в виду, что несправедливо обиженный кандидат - пятно на бренде компании. Сегодня это значит не меньше, чем несправедливо обиженный клиент. - Люди не рождаются победителями, они ими становятся. Кандидата стоит нанимать только в случае, если вы сумеете предоставить ему эту возможность. - «Программист - это не профессия, это образ мышления», (с) программисты. • Проводить интервью, желательно вдвоем с человеком, который будет непосредственно руководить или работать с кандидатом. Это позволит быть более объективным, посмотреть на кандидата с «разных сторон» и лучше его понять. Ваша задача при проведении интервью - получить ответ на 3 вопроса: 1. Знает дело? 2. Умеет его делать? 3. Хочет его делать? От себя: это как раз то, что я называю опыт, талант и старание. • Смена работы это всегда «стресс», который, по мнению психологов, занимает по значению 3-е место после развода семьи и пожара. Помогите кандидату прийти в себя. В противном случае вы будете беседовать с другим человеком. • Принимать решение следует сразу. Возможно, понадобится 5 мин. посоветоваться с коллегой. Не стоит откладывать решение. «Я могу предложить Вам…» Далее должны следовать описание позиции, должностных обязанностей и размера компенсации. Возможно, эта будет другая позиция, а не та, на которую, кандидат изначально позиционировал себя, если, на ваш взгляд в этой роли он будет более эффективен. Обсудите с кандидатом ваше видение его места в проекте. •  Если вы не смогли в ходе интервью снять все сомнения, не берите. Доверяйте своей интуиции. Лучше ошибиться и не взять достойного кандидата, чем рискнуть и получить «проблему». Будьте честны. Имейте волю отказывать: «Я могу предложить Вам…» Далее перечень конкретных отсутствующих знаний и навыков, приобретение которых позволит кандидату, занять данную позицию в будущем. Кандидаты возвращаются! Не стоит отказывать в стиле «Если будет принято положительное решение, мы Вам обязательно позвоним». Это, скорее всего, ложь. Не стоит подрывать доверие к своей компании.

Posted by Vitalii Tsybulnyk on Tuesday, June 16, 2009 6:54 AM
Permalink | Comments (1) | Post RSSRSS comment feed

Мотивация и опыт

Сегодня я продолжу знакомить вас с идеями полюбившейся мне книги Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. Довольно интересным и поучительным мне показался раздел о различной мотивации программистов в зависимости от их опыта. Само это утрверждение отнюдь не ново и, я думаю, очевидно для большинства менеджеров. Однако впервые я встретил цифровые значения (пусть и отражающие грубые оценки), благодаря которым можно учитывать долю различных стимулов в мотивации сотрудника: Потребности Профессионализм Начинающий Опытный Мастер Материальные (зарплата, условия труда, социальный пакет и проч.) 50% 20% - Безопасности (стабильность компании, востребованность технологии проекта на рынке труда, возможность повысить свою квалификацию) - 20% - Принадлежности (возможность учиться у более опытных коллег, опыт участия в успешном проекте, признание в коллективе) 40% 20% 10% Самоуважения (развиваться, делать что-либо лучше других, повышение в должности, самостоятельность и ответственность в работе) 10% 30% 40% Самоактуализации (амбициозность целей проекта – сделать то, что никто не делал или не смог сделать) - 10% 50% При этом пропуск в той или иной графе свидетельствует скорее не об отсутствии соответствующей потребности, а о том, что при помощи дополнительного удовлетворения этой потребности не получится мотивировать данного специалиста. Например, для профессионала материальные потребности и потребности безопасности не играют существенной роли, поскольку, если они в достаточной степени не удовлетворены, он просто меняет работу и больше не думает о них. Приведу также и авторские комментарии к этой таблице:  • Для начинающих программистов хорошим стимулом является само участие в успешном проекте (может быть в первом в их жизни), возможность учиться ремеслу у более опытных и искушенных коллег. • Для опытных программистов хорошим стимулом может служить новизна и востребованность на рынке труда технологий, используемых в проекте (потребность безопасности). Для них также существенны сложность и самостоятельность (потребность самоуважения) в решении поставленных задач. Как правило, я стремлюсь ставить задачи примерно в 1,5 раза сложнее, чем те которые данный программист решал ранее. Для опытного программиста каждая новая задача должна предоставлять дополнительную возможность доказать свой профессионализм. • Сложнее дело обстоит с суперпрограммистами. Их главным мотивом, как правило, служит самоактуализация, поэтому они стремятся решать задачи, которые до них еще никто не делал. Оптимальное их место в проекте - системная архитектура и реализация архитектурно значимых компонентов - скелета системы. При правильной мотивации оставшаяся часть их потребностей принадлежности и самоуважения реализуется через обучение коллег и передачу им своего опыта. На эту деятельность следует планировать до 50% времени суперпрограммиста. Суперпрограммист в проекте должен играть роль технического лидера, который ведет за собой остальных участников под лозунгом: «Делай как я!». Он всегда должен быть готов продемонстрировать, как можно решить эффективно любую задачу в проекте. Вывод, который отсюда следует это то, что на серьезный проект, надо набирать программистов разной квалификации. И начинающих, и звезд. Если вы берете в проект суперпрограммиста, то должны быть уверенным, что вы сможете эффективно использовать его опыт и найдете достойную задачу, которая его заинтересует.

Posted by Vitalii Tsybulnyk on Tuesday, June 16, 2009 5:55 AM
Permalink | Comments (0) | Post RSSRSS comment feed

От группы к Команде

Это ещё один пост из серии наиболее интересных для меня глав книги Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. Итак, все знают, что наиболее эффективной структурной единицей в процессе разработки софта есть Команда, однако многие считают, что Команда - просто группа людей с определёнными знаниями и умениями. К сожалению, всё не так просто. Архипенков приводит следующие характеристики, которые должна приобрести группа, чтобы превратиться в Команду:   Группа Команда Цель Ставиться узкая задача, общие цели не проясняются Ясные, принятие всеми цели и стратегия их достижения Участие в работе Выполнение должностных инструкций и распоряжений Активная позиция, нацеленность на результат, личная ответственность Ролевая структура Строгое распределение ролей, должностей, обязанностей Разделение компетенций. Гибкая структура. Ротация ролей Руководство Администрирование, наличие формального лидера - начальника Лидерство на основе компетентности и доверия, наставничество, помощь и поддержка Принятие решений В основном приказы, и решения принятые большинством Эффективные процедуры принятия решений на основе доверия и взаимовыгоды Конфликты Замалчивание, сокрытие, игнорирование Признание, интеллектуальная конкуренция, эффективное разрешение: «мы по одну сторону баррикады, а проблема с другой» Взаимодействие Закрытость, избегание критики, принцип «не высовываться» Доверие, свобода, проявление инициативы Коммуникация Через формального лидера, служебная переписка Открытость. Уверенность друг в друге и взаимное уважение Творчество Стереотипность, работа по правилам Гибкость и адаптивность. Непрерывное совершенствование и рост компетенций. Раскрытие творческого потенциала каждого Также весьма полезно знать стадии, которые проходит на этапе своего формирования Команда: • Forming (Объединение) • Storming (Разногласия и конфликты) • Norming (Становление) • Performing (Отдача) • Reforming (Расформирование) И ещё много всего полезного и поучительного о Командах есть в этой книге, обязательно прочтите её.

Posted by Vitalii Tsybulnyk on Saturday, June 13, 2009 5:06 PM
Permalink | Comments (3) | Post RSSRSS comment feed

Паттерны параноидального менеджмента

На написание этого поста меня натолкнула одна из глав книги Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. Остальные главы не менее достойны быть обсуждёнными, так что этот пост может стать лишь началом целого цикла. Для тех, у кого нет времени или желания читать всю книгу, настоятельно рекомендую просмотреть хотя бы небольшую заметку как раз об антипаттернах менеджмента, взятых из этой книги. Приведу здесь лишь те "паттерны", с которыми лично мне приходилось сталкиваться в своей практике в порядке от наиболее частых и ярких к более редким. Уверен, вы прочитаете здесь много до боли знакомого: • Руководитель не умеет управлять приоритетами, постоянно занимается пожаротушением, полностью погружен в решение неотложных вопросов. Времени на уточнение целей, разработку стратегии, адекватное планирование, оценку и повышение эффективности применяемых процессов не остается. Героический Темп поступления проблем превышает скорость их решения. Большинство задач, которые получают участники проекта, имеют наивысший приоритет и срочность. Работа постоянно выполняется под давлением нереальных сроков. • Замыкание всех внешних и внутренних потоков информации на себя. Фильтрация и искажение информации в личных интересах. Зависимость исполнителей от более информированного начальника. • Отсутствие делегирования. Строгий контроль всех работ через активное личное наблюдение. Руководитель замыкает на себя принятие решений по всем вопросам. Считает себя самым компетентным. Влезает во все самые мелкие работы. Навязывает собственные идеи. «Просто, делай, как я сказал!» Жестко контролирует каждый шаг исполнителей. • Руководитель, который полностью зависим от Босса. Всегда согласен с его мнением, как бы оно не расходилось с его собственными взглядами и мнением его команды. • В случае провала проекта надеется свалить вину на команду. Если же проект окажется успешным – присваивает успех себе. Культивирует любимчиков в команде, которые никогда с ним не спорят. Постоянный поиск виновных и «козлов отпущения». • Безграничная вера руководителя в методологию с большой буквы «М» - всеобъемлющую теорию того, как следует решать весь класс задач, возникающих в процессе производства. Многоступенчатая бюрократия. Все процессы регламентированы. Применяемые методы ограничены. Инструкции постоянно разрастаются вследствие попыток учесть все возникающие новые ситуации. Внедрены всеобъемлющие нормы и метрики. • Непрерывная критика и понижение самооценки. Постоянные перемещения людей по горизонтали и вверх-вниз. Правила меняются по ходу игры.

Posted by Vitalii Tsybulnyk on Saturday, June 13, 2009 12:11 PM
Permalink | Comments (5) | Post RSSRSS comment feed

Monkey Habits

I've just finished to read an amazing Yuri Shevchenko's 'Monkey Habits' essay so I'm looking forward to share some favorite fragments. Just remember that this "is not about race, nationality or job title", this "is about nature, behavior and attitude". Прочитав замечательное эссе Юрия Шевченко "Повадки обезьян" не смог удержаться чтобы не привести наиболее понравившиеся моменты. Читая их, помните, что это "не о расе, национальности или должности", это "о природе, поведении и отношении". • If a black monkey collects many bananas, it will be given credence to collect even more. If a white monkey produce damage to many bananas, it will be given credence to damage yet more. • Если черная обезьяна собрала много бананов, то ей доверят собрать еще больше. Если белая обезьяна загубила много бананов, то ей доверят загубить еще больше. • As soon as a capable black monkey on its own initiative and effort will develop a desert from scratch into a record yield plantation, a white monkey from a backward stagnating place will arrive. The white monkey will take over leadership and start to teach the black monkeys on how to grow bananas. ... the black monkeys ... will grow and collect a record banana harvest. The white monkey will present this to the other white monkeys as of its leadership success and tremendous achievement. The black monkeys will be sent to the backward plantation to prove their skills again. • Как только способные черные обезьяны самостоятельно и по собственной инициативе поднимут с нуля плантацию бананов и добьются рекордных урожаев, к ним пришлют белую обезьяну с отсталой запущенной плантации. Белая обезьяна возглавит черных обезьян и будет учить их тому, как растить бананы. ... черные обезьяны ... вырастят рекордный урожай, о чем белая обезьяна поведает другим белым обезьянам как о своем выдающемся достижении руководителя. • The white monkeys hold firmly on the trees squeezing their buttocks and balancing their extremities. If one does not now the background, this seems like they are either managing the situation or doing collective masturbation. • Белые обезьяны крепко держатся на деревьях, сжимая ягодицы и балансируя конечностями. Такое размахивание называется «водить руками» или «руко-водить». Со стороны это может напоминать коллективную мастурбацию. • The more staff is in a plantation perimeter security, the more humiliating is the procedure to get a pass and the more strict is the punishment for a black monkey that tried to steel one banana out of the plantation, the more easy and safe it is for a well respected white monkey to steel the entire train full of bananas. • Чем больше охраны по периметру плантации, унизительней процедура оформления пропуска и строже наказание для черной обезьяны, попытавшейся вынести один банан через проходную, тем легче и безнаказанней может белая обезьяна украсть целый железнодорожный состав бананов. • When a white monkey is reading a morning newspaper sitting with comfort in its favorite armchair, the black monkey rushes into the room shouting in panic: «Sir! It’s a huge problem! Fire! We are all in fire! Everything is in fire!!!” Then the white monkey replies without any interruption: “Did you call fire brigade?” and continues to read the newspaper calmly. • Когда белая обезьяна читает газету и в комнату врывается черная обезьяна с криком: «Сэр! Огромная проблема, пожар, пожар!!! Мы горим, все в огне!!!», то белая обезьяна отвечает, не отрываясь от чтения газеты: «А ты вызвал пожарных?» и продолжает невозмутимо читать газету. • The black monkeys do really need to be constantly praised, to be permanently told of how clever they are and to be repeated every time that nothing would ever work without them. The white monkeys do not need that at all. As they know it is true without any appreciation. • Черным обезьянам обязательно нужно, чтобы их постоянно хвалили, говорили какие они умные, и что без них ничего работать не будет. Белым обезьянам это не нужно. Они и так это знают. • There are really many Chief Specialists on Particular Issues among the black monkeys. Such a deep knowledge and such a limited responsibility put sense of worries and scare on the white monkeys. They correctly think that the black monkeys want to make their name, instead of collecting bananas. • Среди черных обезьян всегда много главных специалистов по отдельным вопросам. Такие глубокие познания и ограниченная ответственность настораживают и пугают белых обезьян. Им справедливо кажется, что черные обезьяны набивают себе цену, вместо того, чтобы собирать бананы. • A white monkey does not need to know the black monkeys. It only needs to be able to define between a bad black monkeys and a smart one. If a white monkey made wrong judgment of a black monkey, the white monkey is not found responsible as the choice was anyway made among the black monkeys and they are so unreliable being the black ones. • Белой обезьяне не нужно знать черных обезьян. Нужно только отличать плохих и способных. Если белая обезьяна ошиблась в оценке черной обезьяны, то белая обезьяна в этом не виновата, так как выбор делался среди черных обезьян, а от них всего можно ожидать – ведь они же черные. • When the black monkeys meet among themselves on holidays, they talk only about collecting bananas, as this is the only thing they do. The white monkeys never talk about collecting bananas on holidays, as they never collect bananas. The black monkeys and the white monkeys never meet each other on holidays, as there is nothing common they can talk about. • Встречаясь между собой в свободное время, черные обезьяны разговаривают о сборе бананов, потому что они только этим и занимаются. Белые обезьяны не разговаривают о сборе бананов, потому что они этим и не занимаются. Черные и белые обезьяны не встречаются между собой в свободное время, потому что им просто не о чем разговаривать. • But the black monkeys are always mixing up how to behave, as they cannot define pretty fast who is in front of them: a white monkey or a black monkey. That is why they always get in confusing situations, either saying “Fuck off!” to the big white monkey or starting to lick the ass of the old black monkey in the new-fashioned suit. The white monkey behaves equally with everyone, dependant on what is going on rather than who is in front of it. • Но черные обезьяны вечно путают, перед кем и как себя вести, так как не могут сразу отличить, кто перед ними: – белая или черная обезьяна и поэтому попадают в неприятные истории, послав не того, кого надо, или прогнувшись перед последней черной обезьяной со страусиным пером в заднице. Белая обезьяна ведет себя одинаково со всеми, руководствуясь тем, что с ней происходит, а не тем, кто перед ней стоит. • When a black monkey is delaying banana collection due to the lack of resources or time, the white monkey can easily mention: “O.K. Then I will do it myself.” A chance to watch the white monkey collecting bananas despite all objective obstacles looks ... terrific for the black monkey • Если черная обезьяна затягивает сбор бананов, ссылаясь на очередные трудности и отсутствие ресурсов (времени), то белая обезьяна может запросто сказать: «Ну что же, тогда я это сделаю сама». Перспектива увидеть белую обезьяну, лично срывающую банан, несмотря на все сложности, ... ужасает черную обезьяну • The white monkey, unlike the black ones, is pretty clear on that overall harvest collection result depends on all black monkeys teamwork rather than individual records. Though there may be no individual performance records, the average result is more important in order to cope with plantation size and maintain bananas quantity. So the white monkey orders to put a big “More Teamwork!” slogan on the wall. It also requests the most flexible black monkeys, that have never collected bananas themselves but are willing to teach the others, to avoid climbing palms themselves, to arrange a series of boring and expensive trainings and development courses. On these trainings the black monkeys must draw circles, triangulars and quadrates, they get free drinks and meals, play games without losers and winners. • Белая обезьяна, в отличие от черных, хорошо понимает, что сбор урожая в целом зависит не от отдельных рекордсменов, а от того, будут ли все вместе черные обезьяны сообща собирать бананы, пусть даже и не показывая высоких индивидуальных результатов, – слишком большая плантация, и слишком много на ней бананов, чтобы положиться всего лишь на нескольких передовиков. И тогда белая обезьяна приказывает повесить на плантации лозунг: «Больше командной работы!», а также просит приспособившихся черных обезьян, которые сами не собирали бананы, но готовы этому остервенело учить других, чтобы избежать возвращения на плантацию, провести серию занудных и дорогих семинаров. На этих семинарах черные обезьяны рисуют круги, треугольники и квадраты, их бесплатно кормят и поят, а также играют с ними в игры, где не может быть ни выигравших, ни проигравших. • In a depression, the black monkeys may try to crawl to another plantation but the outcome will be the same every time. It is everywhere and always, that bananas must be collected, and it is nowhere and nothing, that can prevent the white monkey to make a nice presentation about that. • От безысходности и переутомления черная обезьяна-рекордсмен перестает ставить рекорды, но продолжает хорошо и молча собирать бананы. От тоски такая обезьяна может даже попытаться переползти на соседнюю плантацию, но там ее ждет то же самое. Ведь везде и всегда бананы должны быть собраны, и нигде и ничто не должно помешать белой обезьяне сделать об этом презентацию.  

Posted by Vitalii Tsybulnyk on Friday, June 12, 2009 4:25 AM
Permalink | Comments (0) | Post RSSRSS comment feed

В мире животных или Как оценивать работу менеджеров среднего звена

Вопрос оценки работы менеджеров среднего звена (СЗ), на мой взгляд, один из самых сложных в теме оценки эффективности работы персонала. Сложность эта для меня заключается в том, что сама работа менеджера СЗ подразумевает постоянное нахождение меж двух огней: с одной стороны менеджер отдела или команды ответственен за результаты работы команды, т.е. является представителем команды для высшего руководства, а с другой стороны менеджер отдела руководит живыми людьми в своей команде и от него в большой степени зависит удовлетворённость и комфорт его подчинённых, т.е. он является представителем компании для своих подчинённых. В отличие от топ-менеджеров, являющихся в большинстве своём совладельцами бизнеса и никому не подчиняющихся, и рядовых сотрудников, никем не руководящих, менеджер СЗ - единственная роль в служебной структуре, объединяющая в себе эти две функции. С такой точки зрения обязанности менеджера СЗ тоже можно разделить на две основные группы: удовлетворить топ-менеджемент и удовлетворить подчинённых. К первой группе относятся все задачи традиционного "начальника": распределение и контроль задач, сроков, результатов, эффективности и качества, обеспечение дисциплины, структуры подразделения и необходимого результата работы. Ко второй группе относятся обязанности традиционного "шефа": материальная и моральная мотивация, отбор и продвижение кадров, обеспечение здорового климата в коллективе и комфортных условий работы. Если обратиться к миру природы, то коллектив под управлением "начальника" похож на гепарда: даёт очень быстрый разбег (до 75 км/ч за 2 секунды), развивает бешенную скорость (до 110 км/ч), может быстро менять направление бега, но очень быстро перегревается (забег редко длится больше минуты) и из-за огромного расхода энергии гепарду необходимо до получаса, чтобы отдохнуть после погони. Команда во главе с заботливым "шефом" больше похожа на верблюда: движутся достаточно медленно (до 15 км/ч), но может идти без перерыва несколько суток и до 2-х недель обходиться без воды. Я не хочу в этом посте высказывать личное предпочтение какому-то из этих двух животных, так как думаю каждому из них есть своё место в этом мире. То есть сильной компании наверняка пригодились бы в арсенале обе такие команды, что и приводит нас к основному заключению этого поста: оценивать менеджера СЗ нужно по этим двум показателям: умение "руководить вверх" и "руководить вниз". Однако на практике как правило оценкой работы менеджеров СЗ занимается топ-менеджмент или менеджмент более высокого уровня, поэтому для них более естественным и важным в оценке работы является "гепардовая" составляющая: то, насколько хороший для них результат (скорость) показала команда. Что при этом происходит внутри команды, что о начальнике думают сотрудники и как долго такая команда проживёт - вопрос второстепенный. К сожалению, так происходит в большинстве организаций, с которыми мне приходилось сталкиваться. Но, к счастью, не во всех. В компаниях с мудрым руководством заметили, что работа серьёзной и стабильной компании похожа на путешествие вокруг света: благоприятную местность с обилием воды и пищи надо пробегать быстро чтобы первыми попасть на новые угодья, а пустыни надо проходить на верблюдах, чтобы не остаться в них навсегда. Поэтому "верблюжья" составляющая менеджеров СЗ не менее важна для амбициозной компании, чем "гепардовая". Итак, самый сложный вопрос - "почему нужно оценивать и поощрять в менеджерах СЗ умение сделать хорошо своей команде?" - позади. Остался пущий пустяк - ответить на вопрос "как это сделать?". И правда, как оценить умение ублажить высшее руководство - вопрос не такой уж сложный, ведь само высшее руководство знает насколько оно ублажено. Как ни странно, оценить удовлетворённость команды можно ровно таким же простым способом - спросить саму команду. С осознанием этого очевидного правила всё сразу становится на свои места:  - собеседование на должность руководителя команды кандидаты должны проходить не только у высшего руководства, но и у самой команды;  - оценку работе менеджера должны давать не только высшие руководители, но и его подчинённые. Эти два простых правила устраняют очень многие проблемы традиционно постсоветских отношений "ты начальник - я дурак":  - начальника никто не "ставит", его выбирают, поэтому пенять не на кого, если выбрали не того;  - не нравится работа начальника - оцени её низко. Пожалуй я не буду больше распинаться о прелестях такого простого и естественного решения, скажу лишь, что оно точно работает. И пусть не опасаются властолюбивые скептики, при таком подходе производительность не настолько меньше, наскольно команда стабильнее и продуктивнее во времени. Такие команды напоминают мне газелей, которые являются быстрыми бегунами и долгое время могут поддерживать скорость около 50 км/ч.

Categories: Management
Posted by Vitalii Tsybulnyk on Friday, June 5, 2009 4:14 PM
Permalink | Comments (4) | Post RSSRSS comment feed

Технарь vs. Руководитель

Тема противоречивости карьеры "технаря", т.е. технического специалиста, и "руководителя", т.е. менеджера, далеко не нова и весьма актуальна для отечественного IT-сектора. Суть проблемы очень хорошо сформулирована в блогах Сергея Тарасова, Артура Ракитского и во многих других блогах и статьях. Тезисно суть проблемы заключается в следующем:  - В отечественном ИТ секторе сложился стереотип, что менеджер независимо ни от чего должен получать намного больше подчиненных. Очевидное следствие - в менеджеры идут ради более высокого заработка и статуса, а не "по призванию".  - Работа руководителя требует совершенно иных умений, чем работа технаря, прежде всего умелой работы с людьми, поэтому сложившийся стереотип карьерного роста от грамотного инженера к управленцу, мягко говоря, неестественен. Следствие - большинство руководителей не умеет руководить и замещает функцию управления функцией "командования" и "надзирания". Поэтому кажется, что руководителей надо много. Решение проблемы не ново и уже давно успешно применяется во многих западных компаниях: у инженеров должна быть своя карьерная лестница (т.н. Individual Contributor), у руководителей - своя (Manager). При этом сотрудники, находящиеся на одном уровне в этих лестницах, равны и по статусу, и по зарплате. Например, в западных компаниях позиция Software Architect не является руководящей, но имеет статус не ниже (или даже выше), чем руководитель проекта. Что же мешает повсеместному внедерению столь очевидного и проверенного многолетней практикой решения в отечественном ИТ? Более того, западные компании, успешно применявшие это решение у себя "на родине", отказываются от такого подхода, переходя на пост-советский рынок труда. Многие пытаются аргументировать это тем, что местная ИТ индустрия почти не предлагает наукоемких или инновационных проектов, где хороший инженер ценится наравне с хорошим руководителем. Говоря проще, в нашем аутсорсе просто нет места технарям по-настоящему высокого уровня. Однако мой опыт подсказывает, что основная причина проблемы в другом, а именно в самом нашем отношении к роли руководителя: западные руководители смотрят на подчинённых как на партнеров, и такие равноправные отношения помогают общему делу. Жители же бывших социалистических стран в большинстве своем указывают, что на их работах царит авторитарная корпоративная культура, более направленная на удовлетворение непомерного эго начальников, чем на достижение общего успеха. Достаточно трудно разобраться, является ли это "властолюбивой" чертой нашего менталитета, или уже упомянутой безграмотностью наших руководителей.

Categories: Management
Posted by Vitalii Tsybulnyk on Tuesday, April 7, 2009 8:11 AM
Permalink | Comments (3) | Post RSSRSS comment feed

Талант, старание и опыт.

В этом посте я хочу изложить своё мнение по поводу трёх качеств любого сотрудника, наиболее важных для его профессиональной успешности. Тема эта без преувеличения одна из важнейших для любого менеджера, особенно принимающего решения о найме работников. Примером таких рассуждений может послужить, например, эта заметка, которая и подтолкнула меня к написанию сего поста. Итак, качество №1. Кто-то называет ум, в Microsoft называют это "генами", я называю это талант. Суть этого качества в том, что для выполнения любой работы необходим определённый набор данных, склонность к которым может быть (или не быть) у человека с рождения. Например, для программитстов, это аналитический ум, алгоритмическое мышление и ещё ряд способностей, которые трудно сформулировать. Всё это я и объединяю в понятие "талант". Талант очень трудно, почти невозможно развить. Талант невозможно забыть или потерять, хотя некоторые данные могут ослабеть или протупиться. Талант - это наиболее ценное, и в то же время наиболее трудно формализуемое, а значит и трудноопределимое, качество любого сотрудника. Выявить это качество на собеседовании можно только приблизительно по очень косвенным признакам, т.е. как правило его можно только "почувствовать". Качество №2 - старание. Кто-то называет это увлечённостью, кто-то - усидчивостью, кто-то - мотивированностью, кто-то - трудоспособностью, однако всё это - состовляющие одного качества, а точнее даже количества ментальных, временнЫх, энергетических и прочих усилий, которые готов затратить работник на благо выполнения работы. Это качество второе по важности, и в отличие от первого, влиять на него можно, причём влиять существенно, чем как правило и занимается большинство работодателей. Интересная работа, публичное признание, финансовое или иное вознаграждение - вот всё то, что может увеличить (а при отсутствии - уменьшить) старание сотрудника. Однако выявлять это качество на собеседовании можно и нужно, т.к. у каждого старания своя цена, у старания одного сотрудника она очень низкая, у другого может быть непомерно высокой. Понаблюдайте за тем, как человек рассказывает о своих предыдущих работах и проектах. У увлекающегося человека (человека с "дешёвой" старательностью) вы почувствуете "огонёк" даже в рассказе о самом скучном и типовом проекте. Качество №3 - опыт. Кроме количества времени, которое человек занимается определённым делом, сюда ещё входят знания, широта кругозора, образовательная база и т.п. Это качество влияет на истинную ценность сотрудника меньше всего, однако выявить его уровень во всех деталях как правило довольно просто, поэтому на большинстве собеседований "разглядыванию" этого качества уделяется до 90% внимания. Очевидно, что и развивать это качество проще чем два первых. Если с образованием, знаниями и кругозором более менее всё очевидно, то вы спросите, а как же "развивать опыт"? Он либо есть, либо нет, время нельзя заставить бежать быстрее. Всё верно, но мы можем влиять на "плотность" нашего опыта: динамичные не очень долгие проекты, несколько проектов сразу, регулярная (но не слишком частая) смена работы, разные технологии и роли в проекте - всё это даёт ощутимо больше опыта, чем работа над одним проектом в одной роли и в одной компании на протяжении того же времени, хотя здесь вопрос остаётся открытым и я готов выслушать и обсудить другие мнения.

Categories: Management
Posted by Vitalii Tsybulnyk on Friday, January 23, 2009 12:54 PM
Permalink | Comments (2) | Post RSSRSS comment feed

SCRUM в Microsoft.

Момент истины - барабанная дробь, и... Да, в Microsoft испльзуют SCRUM! Не уверен, что абсолютно для всех своих продуктов, но для большинства наверняка. Лично меня это обстоятельство весьма удивило, ведь я ещё помню времена появления и бурного продвижения "водопадно-спирального" MSF, когда достаточно уверенное владение MSF требовалось даже для весьма "попсового" сертификата MCSD. У меня ещё где-то валяются пару увесистых справочников по MSF, которые я планировал когда-нибудь заучить наизусть в качестве "идеального" процесса разработки, который испльзует "сам Microsoft!" Не судьба. Видимо ближайшее время этим справочникам место на свалке, как и любой идеологии, в которую уже не верят даже сами её создатели. Удалось пообщаться со старожилами Microsoft, которые ещё работали согдасно MSF, и работали надо признать весьма успешно. Однако после провала MSF в одном из крупных продуктов (как я понимаю, это был Windows Vista, выход которого был задержан на 2 года в том числе и по причине несовершенства процесса), Microsoft массово перешёл на SCRUM, где пребывает и по сей день. Тем не менее, искушённый читатель нверняка знает, что "провозгласить следование процессу SCRUM" и "следовать процессу SCRUM" - это, как говорят в Одессе, две большие разницы. Поэтому немного о том, как именно в Microsoft соблюдается SCRUM:  - работа над продуктом ведётся небольшими командами по 5-10 человек, в которых присутствуют представители 3-х ролей: Developer, QA, Program Manager.  - работа каждой команды над своей частью проекта разбита на небольшие промежутки времени, sprint'ы продолжительностью 20-30 дней, к концу каждого из которых выделенный "кусочек" функциональности доводится до необходимого уровня готовности, задаваемого в начале спринта.  - внутри каждой команды каждый день проводятся 15-тиминутные SCRUM митинги, задача которых - "держать руку на пульсе" спринта, а именно каждый участник спринта говорит о работе за последние 24 часа и на следующие 24 часа. Если возникают вопросы или есть почва для дискуссии, то назначается отдельный митинг, куда приглашаются только заинтересованные участники. Таким образом оперативно устраняются "блокировки" в работе и всегда можно проследить динамику протекания спринта, затраты времени на ежедневные митинги при этом минимальны.  - SCRUM соблюдается также и в том, что называется "атрибутами процесса", а именно в определённой форме документирования задач и их готовности, сбора метрик и т.п. Вы спросите: а как же тогда известные утверждения о том, что в Microsoft у всех всегда есть менеджер и любой сотрудник находится не дальше чем в 7-ми ступеньках от Стива Балмера? Это правда и в этом "изюминка" реализации SCRUM в Microsoft. Помимо SCRUM-команд, которые формируются динамически согласно требований продукта, и все участники которых выступают как равноправные individual contibutors, все сотрудники ещё входят в состав определённых "статических" команд, которые формируются по признаку специализации (может быть команда только developer'ов или только QA, никаких "смешений"). В этих "статических" командах роли уже распределяются в "классическом" иерархическом представлении: individual contibutor, senior individual contibutor, team manager (например developer - senior developer - development manager или QA - senior QA - QA manager). Состав этих команд меняется намного реже, т.к каждый участник такой "статической" комады может учавствовать в одной или нескольких (или ни одной) SCRUM-командах. Менеджер такой команды является непосредственным "начальником" для каждого члена команды, а у менеджеров команд есть в свою очередь свой "специализированный" (development или QA) менеджер продукта, а у тех - general manager продукта, что и представляет собой известную иерархию Microsoft.

Posted by Vitalii Tsybulnyk on Wednesday, January 21, 2009 11:13 AM
Permalink | Comments (8) | Post RSSRSS comment feed

Немного важных закономерностей

Пройдя несколько тренингов в Microsoft, захотелось поделиться очень занятным графическим материалом. Зависимости, отображённые на приведённых далее графиках, большинству из нас известны исходя из личного опыта или профильной литературы, однако лишний раз посмотреть на визуализацию этих зависимостей, я думаю, будет не вредно. Итак, Зависимость стоимости исправления дефекта от стадии жизненного цикла проекта, на которой этот дефект был допущен: Вцелом график интуитивно понятен и не требует особых комментариев, однако для меня стала приятным сюрпризом "особенность" на графике для деффектов, допущенных на стадии Architecture, в районе перехода от стадии Construction к System test. Предоставляю каждому осмыслить её самостоятельно, скажу лишь что ранее она мне в литературе не попадалась, хотя на опыте мы несомненно её ощущаем почти всегда.   Успешность (вклад) участника проекта на разных этапах разработки: Несомненно, наибольший интерес представляет разделение здесь "объективной" успешности (сплошная линия) и "субъективной" (пунктирная), т.е. видение своей успешности самим участником. Если "объективная" кривая очевидна и понятна всем, по "субъективную" лично я в литературе никогда раньше не встречал и знал о её существовании только интуитивно. Знание и понимание этих закономерностей ценно не только для менеджера, которому это может помочь в нужный момент поддержать мотивацию членов команды и командный дух, но и для каждого участника, т.к. даёт возможность правильно рассчитать самонагрузку и избежать психологических перегрузок. Думаю, сознательное и умелое использование этих знаний могло бы уберечь немало "сгоревших на работе" или "опустивших руки" девелоперов от ухода из проекта и даже сохранить целые команды, однако только в Microsoft я впервые столкнулся как минимум с пониманием и демострацией этих закономерностей.

Posted by Vitalii Tsybulnyk on Monday, December 8, 2008 7:45 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Игра одной рукой, ногами и вдвоём на одной гитаре

Посмотрел на youtube.com несколько "забавных" роликов: one arm guitar, amazing guitar player, Four Hands Guitar и не смог удержаться от аналогий - как ни странно, подобная картина довольно часто наблюдается среди разработчиков ПО. Конечно, если говорить о людях с физическими недостатками, то можно только восхищаться их силой воли и тем невероятным успехам, которых им удалось добится в борьбе за полноценную жизнь. Однако картина резко меняется, когда такой "умелец" приходит на собеседование в ваш оркестр (реальный коммерческий проект), а не в цирковую труппу, и, демонстрируя невероятные трюки, пытается доказать что он и одной рукой (например без знания основ многопоточности) или даже ногами (в текстовом редакторе без дебаггера) может сыграть определённые партии (написать код решения пары хитроумных задачек) не хуже, а то и лучше средестатистического гитариста (программиста). Многие менеджеры, принимающие собеседование, не очень-то сильны в нотной грамоте и охотно "ведутся" на подобное шоу. К сожалению, довольно часто продемонстрированная на собеседовании партия была единственной, возможности (способностей) быстро выучить новую партию нет, а играть в оркестре парень не умеет вовсе... Ситуация только усугубляется тем, что те же не очень дальновидные менеджеры начинают ТРЕБОВАТЬ подобных трюков от ВСЕХ кандидатов: "а ногами вы можете сыграть?" (а теперь то же самое, но без многопоточности), "а есть у вас опыт игры вдвоём на одной гитаре?" (простите мне мой намёк на XP ) и т.д. Причины этого понятны и их две. Первая - человеку с плохим слухом проверить умение играть ногами намного проще, чем умение точно играть по нотам. Вторая - "культ игрока ногами" среди программистов. Культ этот "растёт" корнями из компаний-монстров типа Microsoft или Google, которые как раз славятся тем, что могут попросить на собеседовании поиграть одной рукой или ногами или чем-то ещё . Однако те, кто старается на это ровняться, не понимают двух вещей: 1) ребята, принимающие собеседования в Microsoft и Google, обладают "идеальным слухом" и отлично подкованы, поэтому первым делом они в непренуждённой беседе выяснят ваш уровень владения "классическими" знаниями и умениями, а уж только потом переходят к "трюкам" 2) Microsoft и Google - это не типовой проект на 5 девелоперов, это те, кто рождает будущее, кто не просто красиво исполняет известные партии, а сочиняет новую музыку, или даже придумывает новые музыкальные инструменты, поэтому им как раз может пригодиться и умение играть ногами, и впятером на одном баяне. Однако многие менеджеры всё же видят смысл "перенять лучшее" и последствия такой ситуации часто плачевны - появляется прослойка "гастролёров", выучивших пару таких трюков и мотающихся с ними по собеседованиям, и не задерживающимися на одном месте надолго, т.к. восторги быстро проходят и к "трюкачам" более нет былого уважения, а скорее наоборот. Так они и мотаются, пока им не удаётся каким-то сногсшибательным трюком из своей коллекции сразить кого-то настолько, что им предоставляют руководящую должность. Вот тут уже они оседают надолго, быстро избавляя себя от всех обязанностей, раскрывающих их однорукость, и упоённо дирижируя "нормальными" исполнителями. Ирония заключается в том, что долгое время мытарств и нереализованных требований таки могло научить их тому, как оно ДОЛЖНО БЫТЬ (хотя сделать так они и не могли), поэтому требовать от исполнителей того, что нужно, у них в большинстве случаев получается хорошо. Самые умные к тому же быстро обзаводятся каким-то хорошим исполнителем со слухом и "правильными" навыками и скрывают за ним свою ущербность навсегда. Поэтому лично я на собеседованиях всегда старался больше спрашивать РЕАЛЬНЫЕ проекты и РЕАЛЬНЫЕ задачи, с которыми работали или будет работать девелопер, а только уж потом трюки и фокусы. Второй важный критерий - частота смены работы, но здесь я не оригинален, это уже давно поняли почти во всех компаниях. Этот пост - только маленькая льдинка в теле огромного айсберга проблемы подбора людей и приёма собеседований, но она сегодня сверкнула мне ярче других .

Categories: Management
Posted by Vitalii Tsybulnyk on Thursday, December 4, 2008 6:22 AM
Permalink | Comments (5) | Post RSSRSS comment feed

Необходимо ли нам образование?

Последние посты Паши Подлипенского просто таки цепляют своей актуальностью. Вот и ещё к одному не смог остаться равнодушным. Немного обобщая, сформулирую суть поста. Поднимается наболевший вопрос "какова роль высшего образования в карьере современного ИТ-шника на пост-советском пространстве?" и в качестве ответа предлагается следующий: "При нынешней системе образования польза от ВУЗа стемится к нулю (кроме общения с некоторыми преподавателями-практиками), что признают также и работодатели": от некоторых организаций начали поступать прямые предложения о подготовке именно таких «полуфабрикатов» в течение первых двух лет учебы. В качестве варианта решения проблемы предлагается превратить университеты в почти аутсорсовые компании. И вместо элементарных лабораторных работ на 1-2 курсах выполнять небольшие проекты. В основном саппорт старых продуктов, баг-фиксы. Этот опыт поможет молодым специалистам ознакомиться с архитектурой сложных систем на практике. На 3-5 курсах, уже можно браться за исследовательские проекты и проекты, требующие реализации сложных алгоритмов. Что тут можно сказать?   Во-первых хочется немного "обыграть" утверждение о бесполезности высшего образования. Как мы это можем утверджать? Ответ довольно очевиден - 95% всего, что изучается в ВУЗе, среднестатистическим ИТ-шником потом нигде и никогда не используется. Согласимся с этим. Только ли у ИТ-шников дела так плохи? Думаю что нет. Думаю 95% того что учат будущие врачи тоже им без пользы: ботанику, химию и т.п. Думаю то же самое подтвердят представители большинства профессий. Что же делать? Институт высшего образования исчерпал себя? Копаем дальше. Кто последний раз на работе использовал интегрирование? дифференцирование? законы гидродинамики? формулы органических соединений? стихи Шекспира? А это уже программа старших классов... Как насчёт систем алгебраических уравнений? теоремы Пифагора? стихов Пушкина? пестиков и тычинок? валентности химических элементов? А это уже средние классы пошли... И наконец, кто когда последний раз умножал в столбик? разбивал слова на слоги? делал разбор предложения? нет? А это уже младшие классы! Можно так дойти до утробы матери и понять, что 95% всего, что мы делали когда учились, мы не используем!   Какой тут можно сделать вывод? Не нужно искать в учёбе точных аналогий тому, чем мы занимаемся сейчас. Их быть не может, да и не должно. Когда мы подтягиваемся на перекладине, то в 95% случаев мы не хотим просто больше подтягиваться, мы хотим быть сильнее, выносливее и здоровее, и это работает! Конечно, есть 5% "счастливчиков", которые с детства поднимали гири и потом пошли разгружать арбузы, но если даже грузить арбузы мы не хотим, это не значит что на гири нечего смотреть Возврашаясь к теме высшего образования, не стоит мерять его полезность количеством классов на С++, которые вы потом смогли использовать, или современностью языков программирования, или глубиной изучения сетевых протоколов. Это всё вы без труда освоите сами применительно к тем проектам, над которыми вы работаете. Почему без труда? Да потому что за эти 5 лет в ВУЗе вы научились главному - УЧИТЬСЯ. Вы получили, усвоили и использовали столько разнообразной информации, что стали УМНЕЕ, вы стали лучше УМЕТЬ ВОСПРИНИМАТЬ И ОБРАБАТЫВАТЬ НОВУЮ ИНФОРМАЦИЮ, а это ценнее и труднее всяких конкретных знаний. Конечно, соблазн потратить это время "с бОльшей" пользой велик - за это время можно стать Senior'ом в своей области, но поддаваться не стоит. Шанса получить тот кругозор и "прокачать" свой интеллект уже не будет. Через 7-10 лет разница в опыте сотрётся и вот здесь я делаю ставку на человека с высшим образованием. Я думаю он пойдёт дальше. Кроме того, через 10 лет может появиться совсем новая технология, в освоении которой у человека с высшим образованием огромнейшая фора. Да и новые технологии придумать может только человек, у которого больше запас разнородных знаний и аналогий, чем только опыт конкретной работы.   Но это всё красивая теория... А что суровая действительность? К сожалению, на пост-советском пространстве долговременные инвестиции (которой на мой взгляд является высшее образованиее) не в моде ввиду изменчивости всего происходящено. Все хотят заработать побыстрее и побольше, а иногда это жизненная необходимость, поэтому я не осуждаю тех, кто бросил ВУЗ и пошёл работать - это их выбор и им виднее насколько он верный. Я обращаюсь к тем, кто дошёл до конца и получил эту "корочку" - не жалейте! Может ваши выгоды пока не очевидны, это не значит что их нет. И уж совсем на последок - пару слов ИТ-шникам. Ни в одну ИТ-компанию мирового уровня (Microsoft, Google, IBM...) вас не наймут без высшего образования, а они знают что делают. Более того, на собеседованиях в такие компании только 50% (а то и менше) внимания уделяется вашим профессиональным навыкам, остальное - мышление, логика, математика, алгоритмы и решение проблем - то, что может дать только высшее образование. Не лишайте себя перспектив

Categories: Development | Management
Posted by Vitalii Tsybulnyk on Wednesday, November 19, 2008 11:26 AM
Permalink | Comments (9) | Post RSSRSS comment feed

Как на елку залезть и не поколоться

Зайдя сегодня на любимый блог Паши Подлипенского, встретил там занятный пост с забавным новогодним названием. Пройти мимо я никак не мог, т.к. самого эта тематика не раз волновала, а выбор между стилем "бысто-плохо" и "долго-хорошо" приходится делать постоянно. С одной стороны, неважно, как бысто ты всё сделал, если результат работает плохо. С другой стороны, "дорога ложка к обеду", и история знает много примеров, когда даже очень хорошее ПО оказывалось за бортом по причине несвоевременности. Что же выбрать?  Думаю оба стиля не верны в своих крайних проявлениях, и спешить определяться "с кем ты" не стоит. Можно попробовать следующее: 1. Каждому проекту своя методология 2. Истина как всегда где-то посредине: делайте так долго, как позволяют это условия бизнеса (как выпытать это у заказчика - тема для отдельного поста), и так хорошо, как можете в отведённое время. Думаю соблюдение этих двух правил на протяжении определённого времени при определённой доле удачи может помочь постепенно перебраться в категорию "быстро-хорошо"

Categories: Management
Posted by Vitalii Tsybulnyk on Sunday, November 16, 2008 6:21 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Дай своей конторе второй шанс

Давече наткнулся на занятную одноимённую статью на любимом мною developers.org.ua. Автор выступает от имени HR-менеджера, которому остро наболела проблема текучести кадров в украинском ИТ-бизнесе. Густо  напичканая логическими умозаключениями и примерами из реальной жизни, статья тем не менее сводится к тому, что программисты в большинстве своём народ замкнутый и нелюдимый, как правило не приходит к руководству со своими проблемами, а сразу ложит на стол заявление об уходе. Несмотря на лёгкий реверанс о том, что "менеджеры тоже у нас не очень", в статье явно видна предвзятость автора, что вобщем-то понятно. Намного больший интерес лично для меня было просмотреть комментарии ИТ сообщества к этой статье, по которым очевидно что автор поднял настоящую бурю. Как и следовало ожидать, мнения можно разделать на две основных группы: 1) автор молодец, программисты замучили своим нелогичным поведением и нежеланием помочь менеджерам, которые с ног сбились ублажать девелоперов; 2) автор - яркий пример безграмотного менеджера, а понимать и предвидеть настроение сотрудников - и есть одна из основных задач менеджера. Признаться, я не сразу определился "с  какой стороны баррикад" нахожусь я, однако "выслушав" несколько десятков мнений, понял, что истина где-то посередине. С одной стороны, конечно, прямая задача менеджера - мотивация сотрудников, отслеживание настроений, тим билдинг и т.п. и девелоперы абсолютно вправе ожидать всего этого от своего менеджера. С другой стороны, не стоит забывать о том, что всвязи с молодостью ИТ индустрии у нас практически никто не получает профессионального образования в сфере проектного менеджмента, а опыт 1-2 года уже считается существенным. Т.е. в большинстве своём менеджеры (кстати, как и разработчики!) - это самоучки, поэтому ожидать от них профессионально грамотного поведения не приходится. Корень проблемы - в перегретости ИТ рынка труда, где отыскать хорошего девелопера (кстати, как и менеджера)  - задача совсем не из простых. Отсюда и нежелание девелоперов идти навтречу менелжерам и упрощать им жизнь. Мол, "через дорогу" меня возьмут с удовольствием на таких условиях как я хочу без всяких "но" и "если". Я думаю, пока существует эта перегретость, ожидать что девелоперы будут очень утруждаться и помогать менеджеру догадаться о своих пожеланиях, не приходится. Только дождавшись стабилизации рынка можно ожидать что 1) менеджеры будут становиться всё более профессионально подготовленными и будут не просто "дрючить" девелоперов, а выполнять свои основные задачи, т.е. решать организационные проблемы проекта (среди которых проблема кадров - одна из первых); 2) разработчики перестанут раздуваться от собственной важности и востребованности от того что цена на их труд растёт как снежный ком и станут так же заинтересованными в своей компании, как и она в нём. Тогда и только тогда можно требовать тех "партнёрских" отшений между сотрудником и руководством, которые так хотелось бы наблюдать автору уже сейчас.

Categories: Development | Management
Posted by Vitalii Tsybulnyk on Tuesday, August 26, 2008 7:13 AM
Permalink | Comments (3) | Post RSSRSS comment feed