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

 

В книге Родни Тёрнера по проектному управлению есть интересная классификация проектов.
Он предлагает делить проекты по 2 критериям:
1. Насколько Вы хорошо знаете чего должны достичь

• известно
• неизвестно

2. Насколько Вы хорошо знаете как достигать цели

 

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

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

Кстати, а вы знаете, что первыми упешными руководителями проектов были египтяне? Именно в честь их пирамид, треугольных в профиль, ограничения проекта по срокам, качеству и бюждету назвали “Золотым треугольником”.

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

В принципе, даже подготовку корпоративной попойки можно считать проектом.

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

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

Trac — управление проектом и документацией

Trac — это такая удобная штука, которая позвляет создавать wiki-пдобную документацию и управлять проектом. В нем есть система тикетов для создания планов задач, отчетов об ошибке или запроса на улучшение. Trac может быть привязан к SVN, а SVN к нему, то получается отличная связка для правления кодом. В Svn при фиксировании изменений указываем номер тикета с подробным описанием проблемы, а в Trac пишем как эта проблема решилась.

Проблема

Два дня танцевал с бубном, переустанавливая много раз Trac 0.11.3, никак не мог понять, почему в одном проекте плагин Tags прекрасно работает, а в другом я получаю ошибку

UnicodeEncodeError: 'ascii' codec can't encode character


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

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


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

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

Сегодня я делал краткую презентацию на работе по профессиональному развитию + сертификации и сразу после презентации понял, чего я не сделал. Я забыл задать 2 простых вопросам участникам:

• Вас устраивает ваша должность и зарплата?
• А что Вы делаете такого что не делают остальные чтобы Вас повысили/увеличили зарплату?

Для менеджеров IT-проектов существует несколько видов сертификации, в которых не так просто разобраться. Чтобы вам было проще — объединил информацию по ним в одну таблицу. Включил в виды сертификации то, что достаточно распространено в России, и может помочь вам в вашей карьере.Если говорить в целом, то есть 3 направления сертификации:

• управление проектами — общий подход к управлению проектами. Наиболее известная сертификация — Project Management Professional (PMP)
• жизненный цикл программного средства (Application Lifetime Management, ALM) — включает такие подходы к созданию ПО как RUP и MSF
• отдельные программные средства для управления проектом

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

После безуспешных попыток честно использовать твиттер обнаружил, что кидать в него время от времени кусочки оригинальных мыслей не позволяет скудоумие, а писать «попил молоко», «пошел на улицу» совсем уж противно.
Попробовал приспособить твиттер к делу. Пусть у нас есть какой-нибудь программный проект. Мы создали его из великого чаяния и занимаемся им на голом энтузиазме в свободное время. Несмотря на то, что мы совсем по-взрослому подняли project-tracker, VCS, списки рассылки и Wiki, рано или поздно интерес к проекту угасает. Как-то перестаешь выделять хотя бы 1-2 часа в день на эту работу, забываешь обновлять вики, в трекере повисает куча решенных на 70 процентов задач.
Идея заключалась в том, чтобы приноровить твиттер к созданию у разработчиков чувства постоянной причастности к проекту. Этакого чувства плеча товарища.

Недавно я для себя открыл простую модель, которая обьясняет, какие инструменты нужны менеджеру и команде для ведения и управления проектами.

Все проекты можно разделить на три уровня, по потребности в структуризации и формализации потоков информации и команд. Почему именно это лежит в основе модели? Потому что структура проекта, на мой взгляд, это первое что следует за «стилем управления» и другими неформализируемыми человеческими вопросами.

Побывал я давеча на занимательном и полезном мероприятии под названием

Онлайн тренинг “Как стать менеджером в ИТ”

Занимателен он по нескольким причинам.

Во-первых данный тренинг был бесплатным! Почти… Я только заплатил (а точнее мой работодатель) 4 часа рабочего времени, но это очень дешево. :)

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

Встретили как-то лесной программер Федот и лесной дизайнер Абдул забугорного богатея Джереми. И сказал Джереми: что ж вы, добры молодцы, без дела ходите, талант ваш в землю зарываете? Сделайте мне веб-чудо, золотом оплачу.

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

Одна печаль: Джереми все не ехал заказ забирать да должок платить. Уж и Абдул вороньей почтой писал, и Федот в волшебное скайп-зеркало кричал ему – все без толку, не дозваться было Джереми.

Мы все хотим ставить перед собой и своей командой четкие и понятные цели (задачи), для этого существует несколько критериев, которые собираются в английскую аббревиатуру SMART (умный):

Буква	Английский термин	Русский термин
S	Specific	Точные и конкретные
M	Measurable	Измеримые
A	Achievable	Достижимые
R	Relevant	Релевантные
T	Time bound/framed	Цели со сроком

Статья про «пинание», «закручивание гаек» и контроль задач, разные стили общения и руководства, про сложности делегирования, самомотивацию сотрудников.

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

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



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

Симптомы: падение дисциплины, низкая скорость разработки, потеря энтузиазма.
Свой же стиль руководства я бы теперь назвал «попустительским».

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

Ответ: В 2 словах это,
— Вносите элементарную организованность в процесс. Это не «пинание» — это ваша работа.
— Разный стиль. С крутыми – искренне, с молодежью – дружелюбно, с «примадоннами» – сухо
— Используйте эмоции для «поджигания» людей. Прочитайте Возьмите эмоции с собой
— Используйте 4 модели руководства исходя из задачи и человека. Это вопросы — Может? Возьмет?
— Готовьтесь к тому, что у вас будут проблемы с Директивным стилем и Делегированием.
— Стремитесь к тому, чтобы у вас в команде были только люди с сильной самомотивацией, для которых ваша работа это хобби, страсть, любимое дело. Помогите разобраться в себе другим людям.
— Сплачивайте команду: cобирайте в одной комнате, проводите общие собрания, ставьте общие достойные цели.

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

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



Проект длится 8-ой месяц, будет длиться со всеми многочисленными платформами еще 2-3 месяца. При этом мы сейчас четко видим, какие именно ошибки стоили компании 2-3 месяца разработки и десятки тысяч долларов (надеюсь, что счет на сотни тысяч не пойдет).

КОМАНДА

Главная ошибка в управлении моя — это ошибка выбора команды:
— Ставка на молодую команду, которая так и не смогла, по сути, «развернуться» на этом очень сложном во всех аспектах проекте.
— Связка молодой PM + опытный PMA, которая провалилась сразу. Мне показалось, что я смогу реализовать то, что, мне тогда казалось, работало в Нивале.
— Мы фатально ошиблись с оценкой сложности задачи по гейм-дизайну, что привело к тому, что связка дизайнер-программист оказалась удаленной, что почти катастрофа для проекта нашей сложности.

Мне потребовалось целых 2 месяца, чтобы осознать, насколько плоха ситуация, меня только совсем чуть-чуть оправдывает, что из этих 2 месяцев 2 недели я был в отпуске в тёплом месте. То, что я увидел после отпуска, было катастрофой. Я понял, _насколько_ категорически и масштабно я облажался. Кажется, еще никогда раньше я не ошибался ТАК круто.

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

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

Что должен уметь менеджер проектов? Ничего особенного, все то же что и все менеджеры, русским языком говоря, управляющие. Уметь планировать свою и чужую деятельность, расставлять приоритеты, предвидеть и учитывать риски… Это все, так или иначе, оговаривается в различных стандартах по управлению проектами.

А еще он должен уметь писать. А еще лучше — любить писать. Статьи, презентации, инструкции и много еще чего… И письма! Если вас «повысили» до PM из программистов, смотрите на писанину, как на данное вам Богом утешение за то, что вы надолго, может быть и на всю оставшуюся жизнь, расстались с исходным кодом и языками програмирования. Отнесемся к этой работе творчески, полюбить ее в наших интересах. Воздастся, уверяю.

Итак, напишем письмо заказчику.