• Как продать что угодно кому угодно

    Posted on August 20th, 2010 Александр Орлов 5 comments

    Отличный ролик про то, как продать кому угодно что угодно, если ты инженер или менеджер в проекте. Асхат Уразбаев рассказывает про то, как продавать Agile заказчику, но сам говорит, что так продается все, что угодно кому угодно. И он прав. :)

    Аудио/Видео, Менеджерские навыки, Эксперты

  • Давид Ян о работе с людьми

    Posted on August 19th, 2010 Александр Орлов 1 comment

    Очень хорошее интервью с Давидом Яном, владельцем Abbyy, на тему работы с людьми. Категорически зрелый менеджер, интервью настоятельно рекомендуется к просмотру/прослушиванию.

    Аудио/Видео, Менеджерские навыки, Эксперты

  • 14 шагов к созданию доверительных отношений с заказчиком

    Posted on August 9th, 2010 Александр Орлов No comments

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

    Если что-то из этих 14 способов вы уже использовали - поделитесь в комментариях, как это было и к чему привело. Имхо, многим будет интересно узнать, работает оно или наоборот. :)

    Мария Евграшина “Как завоевать доверие заказчика”

    Пост Саши Орлова с вопросом «как создать доверительные отношения с заказчиком и не потерять его доверия» натолкнул меня на ряд размышлений.

    Ни для кого не секрет, что взаимоотношения заказчик-подрядчик самые непростые.  И не важно, что делает подрядчик: программное обеспечение или, как  было в моем случае, предоставляет pr-услуги.

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

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

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

    1. В команде должен быть порядок, взаимодоверие и прозрачная картина. Когда в команде бардак – заказчик это сразу же почувствует, даже если он с вами практически не общается
    2. Выполняйте обещания. Не давайте нереальных обещаний. Лучше объясните, почему вы можете сделать что-то только к такому сроку, чем пообещаете и не сделаете
    3. Про проблему стоит уведомлять, как только она возникла, а не дожидаться, что она сама собой рассосется. Если проблема возникла, нужно не только о ней сообщить, но и предложить пути решения проблемы, а не взваливать все на плечи заказчика.
    4. Уважайте заказчика и будьте к нему терпеливы. Если вы мило общались с заказчиком по телефону, а потом положили трубку и вслух рассказали, что он такой-сякой нехороший, не удивляйтесь, почему члены вашей команды никогда не станут испытывать к нему уважения, а уж про доверие и говорить не приходится.
    5. Отстаивайте интересы своей команды и коллег в глазах заказчика. Если что-то пошло не так, то стоит признать, что виновата вся команда, а не отдельные Петя Иванов и Вася Сидоров.
    6. Если у вас (по вашему мнению) ужасный заказчик - воспитывайте его. Как? Тут уже вам виднее, то ли своим примером, то ли примером соседних команд, то ли книгами, то ли тренингами,  ищите свое. Как говорится, кто ищет, тот всегда найдет.
    7. Помогите заказчику сэкономить на чем-то.
    8. Нацельтесь на длительные отношения с заказчиком. Узнайте его долгосрочные планы и цели.
    9. Сделайте для него чуть-чуть больше, чем он ожидал.
    10. Будьте скептическими к себе, ищите пути постоянного улучшения, как своей работы, так и взаимоотношений с заказчиком.
    11. Не стесняйтесь иногда попросить у заказчика совет.
    12. Не останавливайтесь на достигнутом. Расширяйте горизонты.
    13. Проявляйте инициативу.
    14. Ну и последнее – клиент всегда прав. Если клиент не прав – то все равно «клиент всегда прав», при этом здравый смысл никто не отменял :-)

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

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

    Хороших и доверяющих вам заказчиков!

    Оригинал статьи

    Менеджерские навыки

  • Коварное проникновение в сознание

    Posted on August 5th, 2010 Александр Орлов 12 comments

    Был в свое время такой бизнес- тренер Карл Маркс, который довольно успешно тренировал массу людей, в том числе после своей смерти. Так вот он сказал довольно неглупую мысль, имхо: “Бытие определяет сознание.”

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

    Если человек смотрит много новостей по телевизору, не подвергая информацию анализу, то у него в голове складывается определенная картина мира в ключе: “Путин и Медведев - большие молодцы”.

    Если же человек подвергает полученную информацию критическому, но не конструктивному анализу, то возникает другая картина: “Все козлы, развалили державу”.

    Если человек, наоборот не смотрит телевизор, а слушает “Эхо Москвы”, то у него может сложиться другое мнение: “Ходорковский молодец, у власти козлы, надо быть несогласным”.

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

    Какое это имеет отношение к работе? Самое прямое. Неоднократно приходилось наблюдать картину, когда на митингах или тренингах инженеры садятся в задних рядах, открывают ноутбуки, абстрагируются от происходящего и начинают пытаться работать. Почему? Ну, потому что выступает HR, или большое начальство, или менеджер, ну то есть, ясное дело, будут промывать мозг.

    Люди, работающие в ИТ - очень умные. Они критически относятся ко всем источникам информации. И прежде всего, к менеджеру, HR’ам и начальству.

    Точно так же, если менеджер что-то говорит менеджеру соседней команды, тот иногда может воспринимать это с подозрением: мол, не просто так наш этот разговор затеял, лицо заинтересованное, в конце года нам с ним бонусы делить…

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

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

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

    Любой человек со стороны вызывает бОльшее доверие, чем свой “промыватель мозгов”. Потому что он - лицо не заинтересованное.

    И после того, как люди впитали в себя этот источник информации, разговаривать с ним становится гораздо проще. Фактически вы начинаете говорить на одном языке.

    Когда вы излагаете своими словами какую-то точку зрения, то а) к вам есть определенное недоверие, как к лицу заинтересованному, и б) получается как в анекдоте: “Мне Битлз не нравится, мне их Раббинович напел”.

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

    Чтобы не ломиться напрямую со своей книгой, можно поступить чуть хитрее. Объявить конкурс на что-нибудь. И победителям и участникам подарить книгу. Или отправить участников на правильный тренинг.

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

    Не надо ломиться в закрытую дверь, подпертую изнутри досочкой недоверия. Иногда продуктивней послать бойца, который через окно убедит ребят, что надо дверь открыть. :)

    Менеджерские навыки

  • Психологические проблемы незаконченного ремонта

    Posted on August 2nd, 2010 Александр Орлов 9 comments

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

    Представьте себе, приходит заказчик к команде работающей по Scrum. Говорит, ребята, когда будет закончен ремонт? Ребята делают оценку бэклога, говорят: где-то примерно через полгода, а через месяц мы тебе сделаем проводку, выровняем полы и наведем желаемую перепланировку.

    Это сразу вызывает у тебя непонимание, потому что у приятеля на работе ремонт сделался за месяц и весь. Причем для бОльшей квартиры. Ты говоришь: как же так, чего так долго? Тебе начинают объяснять непонятными терминами, что все делается полгода, потому что так положено по строительным нормам. Ты говоришь: Ок. А в душе все равно остается непонимание: почему же так долго-то, ведь у приятеля?.. :)

    Проходит месяц, первая итерация позади. Полы выровнены, перепланировка сделана, а проводка почему-то сделана только на кухне. Ты вызываешь прораба и говоришь: как так, обещали закончить проводку, а не закончили? Тут выясняется, что команда не обещала закончить все. Она делала все возможное, чтобы сделать все. Но помешали обстоятельства в лице ПетроЭлектроСбыта, которые не хотели опечатывать новый счетчик.

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

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

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

    НЕДОВЕРИЕ

    Оно возникает не потому, что заказчик плохой. Или потому что команда плохая. Оно есть изначально. Как думает заказчик?

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

    “Вы обещали сделать за месяц, и сделали не все. Как так? Как вам дальше доверять? Я-то обещаю, что выплачу вам зарплату в конце месяца. И выплачиваю. Всю. Обещаю - делаю. Почему у вас иначе?”

    “Вы начинаете с того, что переделываете то, что было до вас. Возникает подозрение, что это для того, чтобы дольше получать от меня деньги. Почему у меня не должно возникать такого подозрения? Я что, знаю вас 15 лет?”

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

    Много поездив по конференциям, я не видел докладов на тему того, как создать доверительные отношения с заказчиком и не потерять его доверия.  Может быть, мы узнаем это на AgileDays или Agileee? :) Если вы побороли такие трудности со своим заказчиком, то поделитесь как. Думаю, будет интересно многим.

    Менеджерские навыки

  • О разделении лидерства

    Posted on July 24th, 2010 Александр Орлов 2 comments

    Нужна ли менеджеру техническая компетенция? Вопрос, настолько часто обсуждаемый, что тут уже непонятно, что и обсуждать. :) Скотт Беркун достаточно подробно раскрыл тему, имхо.

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

    Неочевидное же заключается в том, что менеджер и тех.лид работали в плотном тандеме. Тех.лид, например, в публичных обсудениях никогда не подвергал сомнению авторитет менеджера. Более того, своим поведением тех. лид как бы говорил: «мы работаем вместе, я силен в технической части, ты силене в других вещах - отношениях с клиентами, администрировании бизнеса и т.д.»

    Как писал Роберт Чалдини в «Психологии влияния» большинство людей не имеет своего мнения по каким-то вопросам. Они смотрят на окружающих. В 19-м веке, пишет Чалдини, была распространена профессия «клакер». Это были специальные люди, которых нанимали, когда в театре должна была состояться премьера спектакля. Задача клакеров, сидящих в разных концах зала, была хлопать и кричать «Браво!» и «Бис!». Остальные зрители, которые до той поры сидели в недоумении, то ли спектакль хороший, то ли какая-то непонятная хрень, присоединялись к клакерам. Тем самым утверждая себя во мнении, что спектакль блестящий. Премьера проходила на ура.

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

    Говорит старший инженер про команду тестирования: «Как же они заколебали со своими багами, когда уже научатся спеку читать?!» - нет сомнений, через короткое время студент будет ожесточенно препираться с командой тестирования по любому вопросу. Особенно по вопросу чтения спек.

    Люди берут пример с других людей. С лидеров. А лидеры ведут себя тем или иным образом, потому что они лидеры. Они не смотрят на остальных. Причем, что характерно, они могут вести себя как правильно, так и неправильно. И остальные будут брать с них пример. Такова коварная природа лидерства.

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

    Менеджерские навыки

  • Окно бессрочности

    Posted on April 30th, 2010 Александр Орлов 11 comments

    В недавной вышедшей книге Тома Демарко, Тима Листера, Питера Хрущки и компании “Балдеющие от адреналина и зомбированные шаблонами” среди 86 шаблонов поведения проектных команд есть один, прямо-таки выдающийся. Потому что не одна тысяча менеджеров сложили голову на борьбе с ним. :)

    Это “Маньяна” (Manana). Суть в том, что у каждого человека есть свое окно срочности. И если дедлайн по задаче лежит в окне срочности, то человек начинает оживленно задачу делать. Если же дедлайн пока еще не попал в окно, то человек задачу откладывает “на потом”.

    Например, менеджер говорит команде: “Мы начинаем проект, релиз у нас через полгода. Задачи вроде расписали, давайте начинать делать.” Полгода - это нереально много, обычное окно срочности у людей по утверждениям авторов не превышает одного месяца. Поэтому все машут рукой, говорят “Маньяна” и идут читать башорг. Потому что время еще есть, еще полгода остается.

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

    В институте ситуация другая. Контроля со стороны родителей гораздо меньше. Ты уже свободный человек, эгегей! Все решается в сессию. Ты можешь не ходить на лекции, вообще ничего не делать по предмету. Но если на сдаче курсовика, зачета или экзамена ты зажег и поразил преподавателя своим интеллектом, ты, скорее всего, получишь 5. Преподаватели ВУЗов ценят сиюминутный полугодовой результат, а не процесс. Может быть, это и правильно с какой-то стороны. Но вот здесь и рождается маньяна. Она приходит на замену дисциплине и самодисциплине.

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

    Что с маньяной делать? Да, в общем, рецепт давно всем известен. Побольше контроля. Точнее, почаще контроля. Статус митинги, скрам митинги (они же стэнд-ап митинги) как раз и нужны, чтобы вернуть человека в правильную “школьную” модель поведения.

    Единственное, что нужно начинать их делать сразу, а не ближе к концу релиза. Менеджеры ведь тоже иногда страдают маньяной, они же тоже в институте учились. :)

    Менеджерские навыки, Производительность команды

  • О важности личных встреч

    Posted on April 26th, 2010 Александр Орлов 2 comments

    Опрос про встречи один на один показывает неутешительные результаты:

    65% менеджеров не встречаются регулярно 1:1 со своими сотрудниками

    Когда мы только пришли в Intel, нам всем раздали пакетики с материалами для новых сотрудников. В том числе в пакетике притаилась ручка с надписью “Regular 1:1″. Это неспроста.

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

    Что интересно, встречи 1:1 используются повсеместно. Для многих успешных компаний это обязательная практика. Например, выдающийся советский педагог Виктор Федорович Шаталов в своей книге “Эксперимент продолжается” рассказывал, как он повышал заинтересованность учебой у двоечников и троечников:

    Первые  же месяцы работы в СШ  No  6 выявили  угнетающую картину: треть учеников в каждом классе никак не реагировала на двойки, смирившись с уделом будущих  второгодников. Какими усилиями можно  было расшевелить эту инертную массу? Ужесточением  требований? Бессмысленно. О том, чтобы оставить все как есть, не возникало и мысли.  Выход был только один -  не щадить себя, искать способ вытянуть ребят из  трясины бездумья  и равнодушия. И вот уже в начале первой  четверти  (сентябрь -  октябрь) девятиклассникам было объявлено, что они имеют право  прийти в кабинет  физики во внеурочное время  в  любой день ответить по  тем пройденным разделам, за  которые  получены двойки. Итоговая отметка  за  четверть  будет  выставлена  с  учетом  результатов  ответов  в физкабинете.

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

    Виктор Федорович знает, что говорит. У него все двоечники и троечники становились хорошистами и отличниками. Ведь кто такие двоечники и троечники? Это зачастую демотивированные ученики. А такие сотрудники могут быть у каждого менеджера.

    Встречи один на один - очень мощное средство. Не единственное, конечно, но очень мощное. Use it.

    Менеджерские навыки

  • О личной неприязни и о том, что с ней делать

    Posted on April 19th, 2010 Александр Орлов 2 comments

    Вероятно, многие замечали, что мнение о человеке влияет на мнение о тех идеях, которые он предлагает. Приходит к тебе с классной идеей сотрудник, которого ты искренне считаешь разгильдяем. И в голове вместо восторга мысль: “Блин, лучше бы работал…” :)

    Все дело в том, что вы человека не уважаете и вообще не очень хорошо к нему относитесь. Испытываете личную неприязнь. Один из читателей сайта прислал ссылку на отличную статью Владимира Германа “Личная неприязнь”. Владимир является директором компании Instream, и видно, что знает о чем пишет.

    Избранные цитаты:

    Личная неприязнь - механизм психики. Действие ее коварно и не сразу распознаваемо сознанием. Человек практически не способен мыслить объективно, находясь под действием личной неприязни. Основное вредоносное ее свойство заключается в следующем. Личная неприязнь делает так, что любые высказывания, суждения или поступки оппонента трактуются нашим сознанием как враждебные или с подвохом - действует крайнее недоверие. Даже улыбка человека, у которого просто хорошее настроение, может быть истрактована как враждебная ухмылка или насмешка. В результате, личная неприязнь сама себя вскармливает. В современных коллективах это свойство личной неприязни подкрепляется еще и склонностью оппонентов общаться по электронной почте или ICQ - средства не передают эмоции.

    Например, если один из оппонентов поставил в приветствии восклицательный знак, подразумевая восторженное приветствие адресата, то адресат, испытывающий личную неприязнь, прочитает восклицательный знак как наезд. Необходимо знать это и рекомендовать избегать общения по email и ICQ в случае возникновения напряженности между людьми.

    И еще:

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

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

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

    Прочесть статью полностью

    Менеджерские навыки

  • Скотт Беркун: должны ли менеджеры уметь писать код?

    Posted on April 16th, 2010 Александр Орлов 1 comment

    Разговоры о том, должен ли менеджер уметь писать код, ведутся двести пятьдесят лет. Действительно, такое ощущение, что они начались еще до того, как появился код, программисты и менеджеры. :)

    На эту тему даже разгорелось оживленное обсуждение в мастер-группе Happy PM. И как пошутили там ребята, это обсуждение прочел Скотт Беркун и ответил в своем блоге. :) И добавить к Скотту особенно и нечего. Хорошо написано. Женя Коломыдцев, с которым мы познакомились недавно в Омске, взял и перевел эту статью За что Жене, конечно, большооое спасибо!

    Должны ли менеджеры уметь писать код?

    Автор: Скотт Беркун

    Перевод: Евгений Коломыдцев

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

    Вкратце, это зависит от того, что входит в ваши обязанности менеджера. Если вы занимаетесь только тем, что управляете разработчиками ПО, вам лучше уметь программировать и иметь опыт работы программистом. Отнесем таких менеджеров к категории А. Если вы входите в эту категорию, лишь небольшая часть вашего времени (5-20%) должна уходить на написание кода, и чем больше ваша команда, тем меньше времени у вас должно уходить на код.

    Если же вы ­- босс, ваша основная задача - делать то, что отдельные программисты делать не могут. Вести политическую борьбу, чем не может заниматься другой член команды. Отстаивать новые инициативы и направления. Разрешать некрасивые конфликты. Консультировать. Заниматься организацией тренингов, выбивать бюджет, повышать квалификацию своих сотрудников и находить новых - чтобы команда не переставала расти в количестве и профессионально.

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

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

    • Есть ли между вами и командой взаимное доверие? Речь не о том, как это доверие заслужить, но ответьте на простой вопрос: доверяют ли вам программисты? Они могут вам либо доверять, либо не доверять, и неважно, насколько вы сильны в программировании. Если вы защищаете своих программистов, помогаете им работать эффективно, помогаете им избегать скучных совещаний и других глупых занятий, вы завоюете их доверие. Доверяя вам, они будут вести себя как ваши партнеры и союзники, что поможет обеим сторонам раскрыться и работать в полную силу, независимо от ваших знаний. Как ни странно, часто доверие можно заслужить, вскрывая обман, или, чтобы не создавать конфликта, задавая уместные, умные, неприятные вопросы, которые могут показать, что вы не только понимаете, о чем речь, но вы проявляете искренний интерес. С другой стороны, как лидер, вы должны проявить доверие первым и отказаться от желания контролировать каждый шаг работы, которую вы не понимаете. Иногда можно просто оставить программистов в покое, после того, как вы вместе с ними достигли кристально четкого понимания задач и согласовали сроки их выполнения, и это может стать примером удивительно эффективного стиля управления.
    • Способны ли вы распознавать ложь? В разговоре с подчиненным, когда он заявляет, что поставленная задача сложна, зачастую приходится мысленно прикидывать, что задача а) действительно сложна; б) он не знает, как проще ее выполнить; или в) он просто не хочет этим заниматься. Хороший лидер достаточно компетентен в понимании компромиссов и знает, как устроено программное обеспечение, чтобы вовремя задать пару неприятных вопросов, а то и вскрыть чей-нибудь блеф.
    • Воспринимаете ли вы моральное состояние команды? Моральное состояние не сводится к одним лишь специальным мероприятиям. Кто-то должен понимать, что мотивирует команду разработчиков. Что их вдохновляет, и что подавляет. Возможно, я знаю больше о программировании, чем сотня программистов, которые на меня работают, но если мне не важно, что они чувствуют по отношению к работе, если я не способен их стимулировать, не помогаю им понять, что работа, которую мы делаем, важна, к чему мои знания программирования? Они бесполезны. Лидер, который способен понять, мотивировать, воодушевлять, убеждать, или иногда просто развеселить команду, вносит свой особый вклад, который вряд ли внесет кто-то еще.
    • Понимаете ли вы принципы программирования? Многим бы не помешало пройти краткий курс «Программирование для менеджеров». Есть принципы, которые действительно важны: производительность, объекты, проблемы, связанные со спецификациями, API, основы тестирования, и т.д., и для их понимания не требуются глубокие познания в программировании. Даже немного знаний о том, как работать с HTML/CSS, Flash, или макросами в Excel, преподанных должным образом, могут дать чувство понимания применяемых принципов, и это именно то, что нужно. Не обязательно самому быть технарем, чтобы говорить с технарями и понимать их язык.
    • Можете ли вы помочь программистам принимать верные решения? Самое верное решение - всегда принимать верные решения. Человек в роли лидера (будь то президент, начальник или родитель) часто попадает в ситуации, когда он не являются экспертами, но вынужден работать с экспертами в какой-то области, кто знает намного больше его самого. Есть род мастерства, особый коммуникативный и мыслительный навык, который помогает максимально использовать способности эксперта в принятии решения. Попробуйте задать разработчику два простых вопроса: 1) попросите назвать 3-4 варианта решения проблемы; и 2) попросите назвать плюсы и минусы каждого решения. Это направит разговор в нужное русло, и зачастую верное решение само всплывает на поверхность в ходе обсуждения. Сам факт того, что его слушают, когда программист объясняет разницу между вариантами решения, заставляет его лучше обдумывать решение, в то время как лидер получает важную информацию о контексте задачи, плюсах и минусах того или иного решения, без необходимости самому становиться экспертом во всех этих вопросах. Менеджерам нет нужды быть экспертами - им нужно уметь извлекать практическую пользу из общения с экспертами в любой области. Другими словами, речь идет о своего рода помощи, хотя многие не захотят признавать, что секрет успешного лидерства скрыт в чем то, что настолько завязано на эмоциональном общении людей.
    • Можете ли вы позволить разработчикам помочь вам в принятии верных решений? Часто случается, что описанный подход взаимен. Способны ли вы воспринимать идеи по дизайну, маркетингу или менеджменту от команды разработчиков? Точно так же, как у вас есть представление о том, чем должны заниматься программисты, у них есть свое видение того, чем занимаетесь вы. Еще один способ быстро завоевать доверие - дать им увидеть, что их предложения или обратная связь находят у вас отклик, что к ним прислушиваются, и их отношение к вам изменится.
    • Можете ли вы представить работу программистов в выгодном свете перед другими людьми? Еще одна функция лидера - докладывать о проделанной командой работе, показывать эту работу посторонним. В такой ситуации, скорее всего, придется отвечать на вопросы, касающиеся технической стороны дела, и лидер должен уметь ответить хотя бы на часть из них. Обычно, если лидер вовлечен в принятие решений и понимает учитываемые компромиссы, он сможет ответить на большинство вопросов о проделанной работе. Если лидер этого сделать не сможет, и ему приходится всегда окружать себя программистами, чтобы не попасть впросак, его ценность для команды сомнительна.

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

    Оговорка: Разумеется, ничто не мешает человеку быть отличным программистом и успешным лидером одновременно. Такие люди существуют. Но их встретишь нечасто. А скольких за свою карьеру встречали вы?

    Менеджерские навыки, Эксперты
  • « Older Entries