Прибыль, Cчастливый Разработчик, Истинный Джедай и Совершенный Код

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

Прибыль

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

Путь Истинного Джедая

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

• основы управления проектами (оптимально - PMBoK);
• умение работать с заказчиком: анализ требований клиента, бизнес коммуникация, ведение переговоров, презентативные навыки, бизнес математика, управление временем. Большая часть этих пунктов – стандартные навыки менеджера которыми владеет любой менеджер на западе;
• научится руководить командой;
• освоить концепцию customer service;
• набить с десяток личных шишек управляя проектами.

Это тяжело и в большинстве случаев требует полной перезагрузки собственных взглядов на жизнь. Все, кто учит менеджеров (делают менеджеров из не-менеджеров) об этом знают и стараются максимально ускорить этот процесс. В первую очередь надо настроить группу обучающихся на изменения, заставить из сделать небольшой сознательный шажок вперед к светлому будущему. Подойдет даже такой простой трюк, как договорится с аудиторией снять часы с левой руки и одеть на правую до конца курса лекций. Попробуйте сами 2 – 3 дня носить часы «не на той руке». Физически не сложно, но непривычно и все время напоминает вам зачем вы это сделали. Следующий шаг более сложный, надо суметь показать вставшему на путь менеджмента Другую Сторону (часто для этого используется подача материала в грубовато циничном, прагматичном ключе, что бы лучше проняло). Другая Сторона есть у всего. В любом хорошем можно найти плохое, в любом плохом – хорошее. Менеджер должен уметь смотреть на любое событие, проблему, задачу с разных сторон иначе он не сможет ее эфективно решить. Простой жизненный пример: клиент объявил о сокращении команды разработчиков на 50%. Это плохо: у вас появляется бенч, сокращается оборот и увеличиваются издержки. Однако в этой ситуации есть и плюсы, у вас появляется новые возможности:

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

Понимаю, что на меня сейчас обрушится гнев разработчиков за первые пункты в этом списке. Вернитесь и перечитайте статью Дениса, почитайте его комменты, особенно про 200 часов переработки. Тоже задело? Попробуйте зайти в этом комменте и в списке вверху прагматичный позитив. Те, у кого получилось – записывайтесь к Денису на курсы и добро пожаловать в мир практичных менеджеров (ака, мир чистогана и наживы :) )! Думаю сейчас самое время перейти к теме «счастливого разработчика».

Истинный Джедай и Счастливый Разработчик

Что делает разработчика счастливым: возможность заниматься любимой технологией, писать идеальный код, иметь гибкий график работы, работать без менеджера, работать в дружном коллективе или что то еще? Думаю у каждого есть некая смесь критериев, вес которых постоянно меняется в зависимости от ситуации на проекте, в компании и дома. Каждый, кто спорит на этом ресурсе выражает ту моментальную точку зрения, которая превалирует в данный конкретный момент времени и это вовсе не значит, что завтра его мнение не изменится (хотя публично, тут же на этом ресурсе, этот же человек скорее всего будет продолжать отстаивать свою точку зрения). Менеджер, управляя командой руководствуется простым принципом: проект в полном объеме должен быть сделан в срок. В голове ухорошего менеджера (Истинного Джедая) сущестовует взаимозависимый равнобедренный треугольник: Цель, Команда, Человек (член команды). Другими словами, есть обязательства по проекту – цель, есть команда, которая должна этой цели достичь и есть члены команды со своими настроениями, опытом и проблемами (кто у кого бабу 3 года назад увел...). Если менеджер начнет думать о счастье подчиненных, больше времени уделять прихотям членов команды чем работоспособности команды в целом и достижению цели то выполнение проекта окажется под угрозой. Еще один жизненный пример: Команда убедила руководителя проекта, что их производительность выше если они работают по свободному графику. В команде есть люди, которым, по их словам, удобно начинать работу в 12 дня, есть те, кто приходит к 9 утра и есть те, кто приходит «как получится». Все сотрудники привели убедительнейшие доводы в защиту своего графика и ПМ согласился. Как думаете производительность вырастет? Вопрос хитрый и связан не только с тем, что команда ходит как хочет на работу. Это скорее вопрос про умение данного руководителя проекта влиять на свою команду, добиваться от команды выполнения поставленых задач. В данном случае мы имеем классический пример, когда неумелым менеджером управляет команда. Разработчики будут счастливы до того момента, пока их не уволят или не порежут зарплаты за срыв проекта. Менеджеру тоже конечно. И они, несчастные и обиженные, пойдут на dev.by материть неадекватных топ менеджеров, думающих только о яхтах и бентли, а не о нуждах простых разработчиков... Я считаю что разработчик (да и любой человек в принципе) счастлив тогда, когда его работа получила признание и высокую оценку от тех, на кого и для кого он работал. Тоже самое верно и для руководителей проекта. Если клиент счастлив – счастливы и все кто на него работал. Каждый в этом случае получил свою прибыль (для разработчиков: премии, новый опыт, новый проект, уважение и признание коллег и начальства). Менеджер, добившийся подобного результата может смело звать себя истинным джедаем.

Истинный Джедай и Совершенный Код

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

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.