Управление проектами *

Майкл Шрёпфер (Michael Schroepfer, вице-президент по разработке Facebook, в прошлом — вице-президент по разработке Mozilla) прочитал советы по выживанию программиста в Google и решил вкратце высказать своё мнение об основных ошибках этой компании по управлению инженерией (engineering management).

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

При 1500 сотрудников в Google было больше гибкости и меньше бюрократии, чем в большинстве стартапов на 200 человек. При любом размере Google был лучшим местом для работы среди компаний своего класса. При текущем размере Google — всё ещё более привлекательное место для работы, чем Oracle, Cisco, Microsoft, Adobe, Apple и многие другие хорошо известные фирмы. Именно это делает ошибки менеджмента более заметными.

Вы руководитель компании по производству ПО, директор веб-студии или фрилансер, который хочет вылететь в трубу через пару лет ведения бизнеса? Тогда статья для вас! Я научу вас нескольким ужасным ошибкам, которые позволят медленно и мучительно долго просадить ваше состояние.

Демпинговать, демпинговать и еще раз демпинговать

Сферический заказчик в вакууме хочет разработать некий программный продукт. Вы, компания «А», решили поучаствовать в тендере на его разработку. По вашим оценкам он должен стоить 100 килотугриков. Компания «Б» оценила проект в 50 килотугриков, а компания «В» не поняла техническое задание и оценила проект в 5 килотугриков. Вы просто обязаны демпинговать, и установить цену в 2.5 килотугрика. Вы должны всех перехитрить. Этот проект ведь очень важен для вас, вы и только вы можете его сделать. Пусть конкурент обзавидуется уровню вашего мастерства демпингования!

Я часто задаю вопрос, что лучше, много маленьких проектов по три рубля, или один большой за 30? Что лучше, 30 дешевых работников, или 3 высококвалифицированные специалиста? Спорить можно долго, но правильный ответ находится не в самом вопросе, а за его пределами.

Маленькие проекты позволяют получить высокую доходность при низкой себестоимости. Масштабирование доходов решается путем привлечения новых работников. Форс-мажоры не особо влияют на благосостояние компании. Самое главное, что это быстрые деньги. Звучит очень привлекательно!

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

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

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

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

И вот подтверждение моим словам: bee-cms.ru

Навеяно топиками о книге Rework, самой книгой и топиком "Почему программисты срывают сроки". Я постараюсь рассказать, почему за один месяц изменилось мое отношение к планированию и работе с командой, не без помощи книги от 37signals.

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

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

Вместо введения

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

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

В догонку к посту про макет бизнес модели, не менее полезный «самый короткий в мире маркетинговый план» (так его назвал автор, Келли Одел).

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

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

Проблемы с освоением бюджетных средств бывают не только у нас. Главный инспектор министерства юстиции США сообщил в своем докладе, что перерасход бюджета разработки и внедрения новой компьютерной системы управления делами ФБР превысил 100 миллионов долларов, а работа отстает от графика на два года.

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

 

Привет, хабрадрузья!
Как уже обсуждалось здесь, на русском языке вышла книга 37 signals «Rework».
Хотел бы поделиться с вами своим мнением относительно неё.

Эту книгу ждали многие. В их числе был и я. Rework произвел на меня впечатление еще в англоязычном варианте. Оставалось узнать, насколько он хорош в русскоязычном.

 

Привет!
Какое-то время назад на Хабре была вводная статья в CMMI (Модель CMMI).
Мне повезло лично участвовать в процессе получения организацией 3 уровня этой модели. Хочется рассказать о том, как это происходит на практике.

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

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


Поехал за книгой в магазин. А пока некоторые отрывки из книги и комментарии:

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

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

Что необходимо знать

Я новичок в менеджменте проектов и мне необходимо сформировать кросс-функциональную команду. С чего мне начать и как найти подходящих людей?

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

В последнее время стал часто встречать упоминание роли «Enterprise Architect». Решил покопаться в теме и наткнулся на немного сумбурное, но достаточно интересное обсуждение за круглым столом, что же такое или кто же такой «Enterprise Architect». Возможно, наши коллеги по цеху немного однобоко смотрят на роль «Enterprise Architect» исключительно со стороны IT, но обсуждение в любом случае полезное.

Обсуждение за круглым столом, модератором которого была Дэйна Гарднер, главный аналитик Interarbor Solutions, началось с утверждения:

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

Участники круглого стола, Жанна Росс, директор и ведущий исследователь MIT Center for Information Systems Research, Дейв Хорнфорд, главный специалист по бизнес-архитектуре Integritas Solutions и председатель The Open Group Architecture Forum, и Лен Фескенс, вице-президент направления по развитию навыков и способностей The Open Group, помогли сформулировать следующее:

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

Scrum (stand-up meeting, рус.: летучка) — ежедневное совещание для проектной команды.
(перевод пропущен через призму моего восприятия, хотя с кое чем и не согласен)

Первое – «сложности». Всякое, что вызывает сложности, помехи и мешает продвигаться к цели следует изучить и исключить после летучки. Аджайл использует «теорию ограничений», описанную Эли Голдратт, в которой менеджер должен убирать любые препятствия на пути команды. Менеджер обязан сделать TO-DO список задач после каждой летучки.

Для комментария к топику многовато, поэтому, с вашего позволения отвечу топиком.

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