ManageIT

Учиться, учиться - и еще раз?

Wed, 21 Jun 2006 07:43:08 GMT

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

Краткая предыстория (для тех, кто мою основную ленту не читает). На ВебДевКон меня мое начальство не отпустило ни под каким предлогом. Грустно, конечно. Но keypoint состоит в том, что я, пребывая на месте начальника, сделал бы абсолютно так же..

Обозначу основную мысль: конференции и курсы для сотрудников приносят компании больше вреда, чем пользы.

Возьмем абстрактного разработчика, и, к примеру, тот же ВебДевКон.

Что в плюсе?
+ разработчик учится, повышает свои навыки, и позже применяет их в реальных задачах.
+ разработчик получает сторонний опыт и решения. Это также применимо в своих проектах.
+ разработчик два дня находится в командировочном отпуске :) Качество работы, в большинстве случаев, повышается.

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

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

Это не работает

Wed, 03 May 2006 08:36:15 GMT

Естественно, замечательно сданные проекты, о которых принято говорить в начале всяких руководств и талмудов, с первого раза бывают разве что на этих самых первых страницах. В любой момент возможна ситуация, когда «всё пойдет не так», и разбираться в ней придется также тебе. Пойти к бывшему своему начальнику уже не получится, иногда в силу объективных причин, а чаще просто уже не имеет смысла – это не его дело. Как тут быть.

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

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

Срыв сроков – только твоя вина
Что может в первую очередь испортить жизнь начальнику? Правильно догадались: срыв сроков. Очень неприятная вещь, поскольку последствия имеют денежное исчисление, ошибиться легко, а на этапе планирования все факторы отследить достаточно сложно. Пострадаешь от этого, как и было сказано, в первую очередь ты как руководитель; поэтому, повторяя один из прошлых постов, накинь лишнюю пару недель.

Ответственность в деньгах
Грозить пальчиком и говорить «ай-яй, нехорошо» в наше время уже не принято. Универсальный способ воздействия на сотрудника – был и остается материальный. Кто бы что ни утверждал, основным инструментом мотивации является дензнак, и усваивается такое воздействие лучше.
Однако прежде подумай. Знал ли сотрудник о том, что за конкретную область ответственен именно он? Был ли это его промах, или неверно поставленная задача? Обладал ли он компетенцией для решения задач? Реально ли было уложиться в заданные сроки? Если хоть на один из вопросов ты дать однозначный положительный ответ затрудняешься, то виноват здесь больше ты, чем он.

* ну и конечно, упомянутое ранее «дублирование ответственности» к материальной ответственности отношение иметь, наверное, не должно. Как бы ни были построены командные отношения, основная ответственность регулируется трудовыми договорами.

Слабости и сильности

Wed, 03 May 2006 08:34:43 GMT

Теперь, твоя команда – твой инструмент. Ты можешь себе представить профессионала, который не умеет пользоваться необходимым ему инструментом?

Кто что может
Существует, в принципе, два типа подходов к распределению задач.
Первый – достаточно очевидный: возложить на специалистов соответствующей квалификации задачи, сообразно их квалификации.
Что ты получишь: получишь (сюрприз!) специалистов, способных отвечать за возложенные на них задачи.
Что ты потеряешь: если находится задача, которую ты не отдал кому-то из людей – что ж, придется решать ее самому. Также отмечу, что такой вариант очень плохо масштабируем, и есть способ лучше.

От противного: кто чего не может
Второй вариант – определить, кто чего делать – внимание! – не умеет. И возложить на участников бизнес-процесса двоякие задачи: делает каждый то, в чем он специалист, отвечает каждый за то, в чем он разбирается.
Что это дает: при достаточно грамотной организации руководства ты получаешь команду, которая практически в полном составе ответственна за результат. Покажите мне программиста, который, будучи специалистом в области баз данных, не знаком с организацией сетевой инфраструктуры! И, когда создание сетевой инфраструктуры в рамках проекта дает сбой, «получают», например, трое: специалист по БД (не проконтролировал создание нужного ему окружения), аналитик (не проконтролировал выполнение его требований) и, естественно, специалист по сетям (не выполнил требований и подставил первых двоих).
Что ты теряешь: теряешь ты спокойный сон. Нужно держать достаточно шаткую границу разграничения ответственности: исходя из производственных рамок, ответственность первых двоих из вышеизложенного примера явно надумана – и, скорее всего, им это также известно. Используй доступные тебе средства (мотивация, поощрения, мера ответственности), чтобы удержать процесс работы над проектом именно в таких рамках – и увидишь достойные результаты.

Они не работают вместе!
Еще один момент, который нужно будет учитывать – личные отношения участников твоего процесса. Если известно, скажем, что J не работает в паре с M (потому что один MS-овец, а второй закоренелый юниксоид, и они друг друга на дух не переносят) – в твоих же интересах разобраться в их отношениях до возложения обязанностей. Иначе будет больнее.

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

Я не сделаю этого

Wed, 03 May 2006 08:32:49 GMT

Вернемся к тому моменту, когда на тебя только возложили новые обязанности. Назвали начальником и гордо выдворили из кабинета с ковром.

Пойми, что от тебя хотят
К сожалению, а, может, и к счастью, одинаковых руководящих должностей не бывает. Поэтому, до того, как предпримешь какие-то шаги, определи, что для кого означает твое местоположение на предприятии.
Если ты ранее не позаботился о том, чтобы передать свои программистские обязанности другому – тебе придется довольно долго перекладывать их на плечи других. Очень возможно, что тебе достанется отчетность по планированию, куски аналитики и право подписи некоторых документов. Заблаговременно выясни, какие последствия могут наступить в различных случаях твоего поведения, и какая ответственность на тебя возложена.
И, ради бога, сделай это заранее.

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

Может, это уже сделано?
Если у кого-то из твоего нового подчинения неплохо получается разбираться в чем-то – не парься, пусть он в своем сегменте и разбирается. А как избежать появления второго начальника я уже говорил. Теперь это – твой ресурс, который ты волен использовать по своему усмотрению… на благо бизнеса, конечно.

Аутсорсинг или разделение своего времени
И еще один момент, с которым придется столкнуться. Раньше, скорее всего, работа выглядела так: если не хватает времени уложиться в сроки, либо а) сдвигаются сроки, б) находится больше времени либо в) твои проблемы.
Теперь у тебя появляется еще один способ решить проблему появления дополнительных задач. Я говорю о возможности нанять человека со стороны, в рамках бюджета проекта, который сделает нужную работу. Не самый лучший вариант, принимая во внимание то, что на объяснение обязанностей и круга задач новому человеку ты затратишь, возможно, гораздо большее время, но этот вариант присутствует.

Излишнее звено

Mon, 03 Apr 2006 07:55:45 GMT

Излишнее звено (как не быть передаточным звеном между участниками)

Будем реалистами: невозможно уметь и понимать абсолютно всё. Скорее всего ты уже это понял – иначе бы не был начальником. В твоей команде работают люди, являющиеся специалистами в своей области. Которые поймут друг друга куда лучше, если ты не будешь им пересказывать их же слова.
Есть огромное количество случаев, когда игра в «испорченный телефон» проекту в плюс не пойдет. Однако, допуская прямое взаимодействие, ты «выпускаешь из рук» своих людей.

Когда нужно прямое участие
Золотое правило: твои люди, оставшиеся без твоего присмотра, должны знать, что присмотр есть. Прямое твое участие нужно также в том случае, если общение происходит со сторонними специалистами.
Я для себя решаю так: большинство переговоров «напрямую» проходят с моим участием. Чтобы не расслаблялись.

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

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

Как выправить упущенное
Очень просто, на самом деле: ввести отчетность. Потребовать от участников письменного отчета по проведенной ими встрече. Всё сразу встанет на свои места, вот увидите!

* Самое большое достижение – когда команда делает нужные вещи сама, но держит начальника в курсе… простите, увлекся.

Совещания

Mon, 03 Apr 2006 07:02:18 GMT

(что ждать, чего не ждать от совещаний)

Немножко злободневного. Совещания.
Что есть совещание?
В обычном случае это – группа людей, которые собраны воедино для того, что обсудить проблемы (раз) и что-нибудь решить (два).
Это не работает, и не надо тешить себя надеждой, что люди всегда могут договориться.

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

Кто побеждает в совещании
Есть все же небольшой процент встреч коллективного общения, когда решения выносятся. Но, опять же: не стоит слепо верить в людскую рассудочность. Победит то решение, которое покажется – именно покажется – наиболее правильным. Следовательно, победит тот, кто приложил больше усилий по приданию именно такого вида.

Не решай ненужного
Если, не дай боже, ты решил что-то вынести на совещание – подумай, а не решено ли это уже на текущий момент (неважно, с тобой или без тебя). Проще вызвать к себе наиболее понимающего человека (из «уже решивших», ага) и пообщаться с ним лично, чем тратить время, свое и людей.

Ограничь время
Главный минус подобных мероприятий – время. Методология XP, как ты, наверное, помнишь, предлагает решение «стоячие собрания». В этом есть куча здравого смысла, но использовать такой подход удастся вряд ли (разве что в том случае, если собираются только твои подчиненные). В любом случае лучше жестко задать временные рамки, и, при надобности, расписать timeline.

Удачных совещаний.

Чего хочет начальник

Fri, 24 Mar 2006 07:39:41 GMT

(твоя роль в чужом плане)

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

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

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

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

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

Только он знает эффект
Посмотрим на ситуацию с обратной стороны. Ты, как руководитель, да и программист, можешь отвечать за свою – и только за свою сторону задачи. «У вас было всё плохо, а станет всё хорошо» - детский лепет: только заказчик/твой руководитель сможет обоснованно сказать, имеет твое решение ценность либо нет. Think about it.

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

Продать то, чего нет

Fri, 24 Mar 2006 07:31:02 GMT

(что стоит за презентацией)

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

Разочарую. Начальник (основной слушатель и зритель подобных представлений) не поймет ничего. Более того, скажу: он просто обязан быть дураком, чтобы не мешать тебе работать. Он, например, торгует чугунными котлами, и знать не знает ничего про ай-ти: ну, разве что слово такое слышал от дочки. Он торгует, получает деньги, и ты для него – тот, кто хочет эти его реальные деньги забрать себе, взамен предложив купить некий объем воздуха; любой IT-продукт суть воздух, что бы мы тут не говорили.

Кто будет слушать
Потребителями твоих изысков могут быть три стороны: сторона твоя собственная, т.е. команда, которой нужно привить понимание значимости исполняемого дело и разъяснить детали общего видения; сторона начальствующая, т.е. начальник или заказчик, которому нужно показать эффект выгоды от проделанной работы; и сторона третья aka непонятная, которой надо объяснить то, что она попросит.

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

Кто они? Психология в действии
При подготовке своего выступления перед людьми (с привлечением технических средств, или без них) продумай, первое – что ты хочешь сказать, второе – кому. О типах восприятия распространяться не буду, найти можно в любом пособии по психологии для начальных курсов университета, но чем больше ты знаешь «общего» про своих слушателей, тем проще будет подобрать образы, которые на них воздействуют.

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

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

Сроки проекта

Fri, 24 Mar 2006 07:27:41 GMT

(размечаем карту)

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

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

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

Ты не один: координация с проектными группами
Если твоя работа зависит от кого-то – постарайся получить результат их работы не в официальном варианте, а еще в draft-е, этим ты сэкономишь время на анализ проекта. Разумеется, обязательно укажи зависимость твоих сроков от сроков другой команды. Если же от твоей работы зависит кто-то – постарайся предоставить наработки раньше срока, плюс увеличь срок еще на треть заранее.
За-ра-не-е.

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

Что сначала, что потом
Здесь метод такой: сначала делаем то, что определяет ключевые возможности проекта. На это должно уйти 30-40 процентов рабочего времени. Далее реализуются детали и интерфейсы. Это можно делать параллельно, займет ориентировочно 30 процентов времени. Оставшиеся 30-40 процентов уйдут на тесты. Замечу, что это именно рабочее время, не считая времени на аналитику и внедрение.

Можно ли их менять
Подумай, прежде чем написать дату. Вопрос, что лучше: сказать неделю и сделать за три, или сказать четыре и сделать за три?

Сдвиг неприемлем?
Именно так. Проект, который не выполнен в срок – не выполнен.

Сделай мне хорошо!

Thu, 23 Mar 2006 08:52:20 GMT

(подход к степени участия в бизнес-процессе)

Неверно то утверждение, что задача компании - продать продукт. Более того, скажу необычную вещь: ты продаешь (или создаешь для компании) не продукт – ты создаешь идею. Которая меняет бизнес-процесс, корректируя его исполнение в сторону меньших затрат и большей прибыли. Либо в соответствии другим поставленным задачам.

Можно решить задачу, можно решить проблему
Как связаны продавец гаечного ключа и механик по найму? Вполне очевидно, что бессмысленно требовать от продавца ключей починки двигателя машины. Но – think again, it’s IT! – в айти-сфере подобное случается сплошь и рядом. Разграничить предлагаю так.

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

Есть продажа инструмента. На этом этапе, кстати, до сих пор остается, например, российская разработка сайтов. Да и не только она. Продавать инструмент – внимание! – можно только специалисту, который умеет им пользоваться. Конечный заказчик, конечно, при некоторых навыках найдет, куда его приспособить, но «это не хороший бизнес».

Что нужно заказчику
Сюрприз! – заказчику нужно решение его проблем.

Поэтому грамотнее продать заказчику решение. В этом случае твоя команда создает нечто, что можно применить уже в его собственном бизнес-процессе. Это важно. Если заказчик начинает менять бизнес-процесс под решение, то это в 80 случаях из ста неграмотное позиционирование либо неграмотное исполнение решения.

Самый же доходный (и самый сложный одновременно) путь – это продажа результата. Для высококлассного исполнения тебе придется быть экспертом в двух областях сразу: области знаний IT и области знаний сферы заказчика.

Готова ли команда?
Посмотри на задачу. Ты хоть примерно знаешь, как ее решить? Действительно ли твои люди способны ее решить, или тебе просто удалось убедить в этом заказчика? Справятся ли они? Владеешь ли ты ситуацией?

Одна ошибка и двадцать лет поддержки
Радуйся: права на ошибку у тебя нет. Теперь это твоя постоянная задача – определять, будет ли работать хорошо то, чего еще нет в природе.

Давай руководить!

Thu, 23 Mar 2006 08:33:31 GMT

(что должен делать руководитель: для новичков)

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

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

Отличие исполнителя, руководителя, координатора и аудитора
Человек, который что-то делает – это исполнитель. У него есть задача, ее можно измерить, ее можно оценить, ее можно изложить или делегировать. Это теперь делают твои подчиненные. Руководитель – это персона, которая следит, чтобы максимум задач выполнялся в срок, и перекладывает работу на плечи своих подчиненных. Координатор призван консультировать людей по пониманию задач, и ставить сроки. Реальные сроки. Аудитор же только следит за выполнением задачи в срок.

Но если ты думаешь, что у тебя есть выбор – ты ошибся. Всё это придется теперь делать тебе. Разве что исполнение ты вправе делегировать.

Кем ты будешь
Все ли знакомы с цитатной фразой Жени Забокрицкого «…надо уходить куда-то, где не пишут код!»?. Выбери себе амплуа из предложенных ранее, и постарайся ему следовать. У каждого из них будут как плюсы, так и минусы, но одного не будет точно: гарантий правильности. Что вообще мы можем гарантировать в этом мире?...

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

Большая ответственность
Просто так ничего не случится, и теперь ты в ответе за людей. Твоих людей.

План заметок

Thu, 23 Mar 2006 08:16:29 GMT

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

- Раздел «Люди и задачи» посвящен собственно тому, с чего приходится так или иначе начинать руководящему человеку: есть ресурсы, есть задачи, и нужно, чтобы этот механизм работал, причем, как обычно, «deadline был вчера!». С чего начать. При этом упор именно на то, что в команде работаю люди, и от правильного осмысления этого факта может зависеть очень многое.
- «Задачи и решения» призваны осветить работу группы с другой стороны: со стороны выполняемой работы. Механизм должен работать эффективно, и ключевые моменты постараемся рассмотреть.
- На новоявленного руководителя сразу ложится ответственность по написанию макулатуры, причем, как ни прискорбно это слышать, за написанные планы, сроки и анализы придется отвечать. Выделил в раздел «Решения и планы».
- С другой стороны, со стороны заказчика, бывший программист должен уметь делать еще одну вещь: он должен уметь давать гарантии и отвечать за них. Что работает, а что нет, и чего лучше избежать на раннем этапе мы рассмотрим в разделе «Планы и гарантии».
- «Гарантии и ожидания» показывают процесс с третьей стороны, со стороны заказчика, поскольку для него команда разработки, равно как и ее начальник – еще один ресурс, контрагент, внешний риск и бизнес-процесс. Предупрежден – вооружен, а заказчика лучше знать в лицо врагом, чтобы принимать его как друга.
- Ну и завершает цикл раздел «Ожидания и люди», поскольку все равно всё зависит от членов бизнес-процесса. Кто-то считает, что может большего, кто-то решил уйти, а кому-то просто есть что сказать – и тебе придется его слушать, ты ведь теперь начальник.

Помимо мыслей приведу еще один класс заметок – это «быстрорастворимые решения», или тот руководящий опыт, что проверен на своей шкуре.

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

Вступительное слово

Thu, 23 Mar 2006 08:14:44 GMT

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

Что привело меня к такой идее? Просто именно тогда, когда я начинал как-то разбираться со свалившимся на меня менеджментом, не было никого, кто мог бы сказать «а вот это мы делали так», или «грамотнее сделать по-другому». Я бы действительно много отдал за подобные советы, но, по той причине, что их просто взять было неоткуда, пришлось испытывать всё на собственной шкуре.

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