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

После трех лет использования Basecamp для ведения проектов, мы нашли то, что нам подходит больше. Предлагаю хабрапользователям ознакомиться с сервисом ведения проектов http://unfuddle.com, его достоинствами, недостатками и его сравнением с Basecamp.

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

Учет задач мы ведем не в солидном таск-трекере, а в… текстовом файле. Точнее не просто текстовом, а в расшаренном документе Google Docs. Происходит это так:

• Записываем возникающие задачи обычным черным шрифтом в виде обычного ненумерованного списка.
• Размером шрифта отмечаем приоритет задач — чем крупнее, тем важнее.
• Цветом помечаем задачи, назначенные на конкретного человека — за каждым разработчиком закреплен свой цвет.

В начале файла обычно помещаем "легенду", чтобы всегда можно было вспомнить, где чей цвет. Вот как это выглядит:

В Минске мобильный оператор life:) устроил для студентов лекцию-введение в управление проектами.
Ведущий семинара — Нейат Мурат Эркан, Президент ассоциации проектного менеджмента Стамбула (IPYD), поделился мировым опытом в этой дисциплине.

Полтора часа выступления и презентация (english only)

Из интересного — ассоциация IPYD бесплатная, за участие в ней никому ничего не платят. Равно как и не платят президенту. Сама организация — на добровольных началах.
Но при этом в нее принимают только после экзаменов.

Введение

Думаю, многие из вас слышали выражение «9 женщин не могут родить ребёнка за 1 месяц!». Контекст этого выражения очевиден — в разработке ПО его применяют в качестве аллегории, когда протестуют против совершенно неприемлемого сжатия сроков. Здесь под сжатием понимают сокращение сроков разработки путём расширения команды при сохранении общей трудоёмкости разработки.


Совершенно очевидно, что сжимать сроки до бесконечности невозможно. Существует определённый предел. Например, известным экспертом в области оценки трудоёмкости разработки ПО Стивом Макконнеллом (Steve McConnell) этот порог определён как 25% от исходных оценок (см. мою предыдущую статью).
Но этот топик не об оценках трудоёмкости…
Вот я выше написал «совершенно очевидно...». Думаете, это действительно очевидно? Всем?
Мой недавний опыт показал, что это очевидно далеко не всем. Проект был очень крупный и срок сдачи неумолимо приближался. Было принято решение резко расширять команду, чтобы успеть. Довод про «9 женщин» никто не принял. Команда была расширена и в срок мы всё равно не успели. Можно ли было как-то, кроме как на словах, показать, как будут развиваться события? Вот о том, как смоделировать такую ситуацию, и будет моя статья.

Доброго времени суток!

Хочу рассказать про интересный результат мозгового штурма, который мы провели на прошлой неделе.

Интересность момента заключается в том, что мы переосмыслили возможности Gantt диаграммы для работы с Agile проектами. До штурма, я и мои коллеги думали об этой диаграмме как об одном из многих способов отображения плана проекта и его прогресса. В таком приближении мы имеем список задач, список разработчиков, календарь и массив отчетов от команды о прогрессе, которые можем показывать в разных представлениях — Gantt, PERT и Backlog.

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

Свершилось! Cегодня появилась в продаже новая книга Джейсон Фрид (Jason Fried) и Дэвид Хейнемейер (David Heinmeier) из 37signals. В книге рассказывается о принципах управления всем известных проектов этой студии. Rework идейно дополняет книгу Тима Ферриса (Tim Ferriss) «The 4-Hour Workweek».

Доброго времени суток.

Я пришел в управление проектами из программирования. То есть, нет так давно, я еще писал код и мне это очень нравилось. Меня мало беспокоили волнения, происходящие где-то на верху — «у менеджеров». Все поменялось в 2004, когда меня назначили тим лидом.

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

Тогда я начал задумываться о причинах такой ситуации, начал читать посты и книги по менеджменту. Как программист, находящийся под впечатлением революционных архитектурных решений — таких, как MVC и паттерны Фоулера, я полагал, что есть *техническое* решение наших проблем с менеджментом — нужно его только отыскать и применить.

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

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

Привет, Хабр.

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

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

Что такое хорошо

Договор — это хорошо. Хороший договор — ещё лучше. Я искренне рад, что есть люди, согласные с этим. (Именно люди: ибо не один, не два, не три и даже (остросюжетный триллер) не четыре человека.)

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

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

Отсюда вывод № 1: сейчас нельзя назвать ни один из имеющихся (в том числе, здесь, на хабре) договоров хорошим. Но это ещё не всё.

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

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

Итак, наконец-то мы решили начать писать спецификации. Поскольку сам процесс для нас новый, пускай хотя бы инструменты будут привычными.
Что мы хотим от инструмента? Пожалуй, все требования сводятся к одному слову — удобство. Ведь нужно иметь очень веские причины, чтобы заниматься чем-то, если это делать неудобно. А ведь нам хочется, чтобы наши коллеги получали удовольствие от написания спецификаций. Как, например, от программирования.

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

Позволю себе вольность начать серезную тему с шуточной аналогии, дабы поднять Читатель, Ваше настроение и раскрепостить сознание. Для тех кто в танке не видел классическую сагу *звездные войны* — речь идет об использовании таинственной Силы, о чем шептал призрак Оби Вана Люку Скайуокеру (на фото) и, что в конце концов помогло ему (Люку), используя легкий истребитель, порвать подбить вражескую военную станцию планетарных размеров одной ракетой.

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

Природа одарила человека мощным интеллектом, который представляет модели окружающего мира в серой логике. Представьте, что вы создали объектную модель, коды методов в которой оперируют не черно-белой (ЧБ) логикой (true — false или 1 и 0), a серой, где логическое выражение может иметь значение 0.7 или даже 0.5. И это значение может мутировать, подстраиваться под изменения окружающего мира.

Наши средства для общения, книги, методы обмена идеями сильно отстают от таких моделей — поскольку они используют ЧБ логику.

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

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

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

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

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

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

Итак, продажи в веб-студии делятся на три типа:

• Новые продажи со входящего потока (заказчик обращается с запросом сам). Расширение данного канала – основная задача внешнего маркетинга и PR компании.
• Повторные продажи по текущим клиентам. Увеличение продаж по данному направлению – одна из важных задач службы клиентского сервиса.
• Холодные/активные продажи (инициируется контакт с заказчиком, который не проявлял до этого интереса к компании).

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

Сразу оговорюсь – ни про какой спам и прочие массовые безадресные акции речь не пойдет.

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

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

Совершенно случайно набрёл на одно интересное видео под названием Situating Personal Information Management (PIM) Practices within an Organization, почитал документ(создатели PIM подошли к этой проблеме основательно — исследования, тесты, теории, мне кажется, некоторые даже защитили кандидатские и докторские по этой тематике) и оказалось что те guidelines для организации хранения информации и быстрого доступа к ней, которые изложены в статьях, я уже давно и успешно использую в своей повседневной работе. И появились они у меня, как вы понимаете, не от хорошей жизни.
Так уж получилось, что работая ПМом, количество проектов у меня не опускалось ниже 5 и стабильно держалось в диапазоне 5 -10. Проекты были в основной своей массе небольшие, где то 3-5 месяцев длительностью и 2-4 разработчиков (ну и плюс сетевые администраторы, тестеры в проектной команде). Но когда к этому богатству добавился production support и maintenance и количество важных писем перевалило за 50-70 в день, пришлось задуматься насчет эффективного структурированного хранения проектной информации, её поиска, напоминаний о запланированных событиях. Далее описание что и как получилось...

Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.