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

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

И в это понятие входит слишком много всего, начиная с правильно спроектированного сайта (интерфейс, тексты, seo-подготовка), заканчивая его поддержкой и рекламой.

Чтобы ничего не забыть, рассказывая клиенту о том, что может быть, мы составили схему, которую назвали «Элементы комплексной стратегии присутствия в сети Интернет» (PDF, 145 Kb).

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

Эта первая версия схемы — так что любые дополнения и комментарии приветствуются.

Спасибо.

update 1: главный идеолог схемы podluzny отвечает на вопросы в комментариях ;-)

update 2: майндмап выложим чуть позже, но любой желающий минут за 20-30 может повторить эту схему, вся информация представлена.

(2009 год, второе письмо старшего менеджера веб-студии — младшему)
Итак, первоначальные переговоры c клиентом проведены. Смотрим первую часть методички здесь http://habrahabr.ru/blogs/studiobusiness/45543/.
Теперь надо сориентировать клиента по цене. Если он с ней принципиально согласен — переходим к обсуждению Технического задания (ТЗ).
Делаем смету

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

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

Ничто не предвещало (преамбула)

Приходит посредник (или представитель заказчика), приносит концепцию (почти всегда гордо именуемую ТЗ) и просит оценить фронт работ в человеко-часах или баксо-рублях. После просмотра предоставленного документа я прикидываю, что работа займет около x (икс) недель и будет стоить примерно y (игрек) денег. Оценочная прикидка, ничего более. При оценке учитывается, что ТЗ (концепция) штука достаточно расплывчатая, чтобы при его уточнении можно было бы упихать функциональности раз в 5 больше, чем нарисовано изначально и сам проект выше среднего по сложности, причем не социальщина какая-нибудь, а программно-аппаратный комплекс взаимодействующий ещё и со сторонними приложениями. Оценки высылаются запросившему. В ответ приходит письмо с просьбой расписать чуть подробнее. Опускаюсь на уровень ниже выделяю какие-то наиболее существенные подпроекты, высылаю. Получаю замечательный ответ: «Вы просите так много, что я даже не буду показывать это заказчику.» Где-то рядом крутится смайл с ВОТ ТАКИМИ глазами.

Прошло много времени, прежде чем я созрел на написание второй части статьи, посвященной управлению конфигурациями. Тому, что это наконец таки свершилось способствует тот факт, что не так давно мне посчастливилось выступать на конференции PHPCONF 2009 8 октября (Web Architect Workshop Day) с мастер-классом «Метод организации репозитория исходного кода». Для выступления были заблаговременно подготовлены презентация, а также текст доклада. Несмотря на отличную организацию мероприятия, для публичного доступа так и не были выложены материалы докладов, входящих в программу конференции. В качестве компенсации я решил таки опубликовать материал, использованный в моем выступлении. Кроме данной статьи, (которая является логическим продолжением предыдущей), посвященной конфигурационному менеджменту, для публичного обозрения доступны слайды презентации.
В данной статье пойдет речь об инструментах, использующихся при управлении конфигурациями. Поэтому в первую очередь хотелось бы заострить внимание на том, как инструменты, использующиеся в разработке могут влиять на процесс создания ПО.

Добрый день, коллеги!

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

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

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

Итак, процесс создания посредственного сайта…

Автор изображения: wiseacre.

Кто виноват?

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

Приветствую. Как и обещал — продолжение цикла заметок об управлении конфигурацией ПО, в простонародье называемом Software Configuration Management. Весь цикл можно найти по ссылке на тэг CM. Из ещё неохваченного осталась буквально пара заметок.

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

На рынке важно быть сфокусированным. Что ты продаёшь? Веб-программирование или «сайты под ключ»? Чем ты занимаешься? Разработкой сайтов или бизнесом? Возможно, ответы на эти вопросы кто-то найдёт в моем докладе на третьей «Сибирской Интернет-Неделе». На частном примере перехода с самописной CMS на коробочную в студии Kinetica я хочу начать разговор об оптимизации бизнес-процессов в любой российской веб-студии.

В IT индустрии все чаще встречаются проекты с распределенными командами. Это удобно — спецификация, код, баги, мануалы легко перемещаются из одного конца планеты в другой за доли секунд. Это выгодно — аутсорсинг проектных процессов, будь то разработка, тестирование или саппорт, в Индии или Китае обойдется в 3–5 раз дешевле аналогичных сервисов в странах Европы или США.

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

 

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

Так вот — о формализации. Намедни провёл опрос с целью выяснить — какие метрики народ использует в своих проектах. Выяснилось страшное. Из тех, кто вообще решил что-то выбрать (т.е. без воздержавшихся) — половина не просто не собирает метрики, но и не собрается. Надо полагать, с документированием процессов всё ещё хуже.

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

 

И снова здравствуйте.

Продолжаю публиковать цикл статей о SCM — управлении конфигурацией ПО.
3 предыдущие заметки можно прочитать в этом же блоге.

Сегодня расскажу о том, с чем работает большинство читателей — о контроле версий.

Disclaimer

Далее будут описаны основные техники, реализованные в подавляющем большинстве систем контроля версий. Как они реализуются в приложениях, которые использует читатель, оставим на откуп многочисленным руководствам пользователя, how-to, FAQ и прочим документам, коих можно найти без труда. Главное – понять, по каким принципам и зачем оно работает именно так.

 

Вместо предисловия

И снова доброго времени суток!

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

1. Цикл статей по основам Software Configuration Management. О том, что такое СМ, каковы его задачи и за что отвечает в рамках проекта CM-инженер.
2. Software Configuration Management // Конфигурации и baselines. О том, что такое рабочий продукт в терминах SCM, что такое конфигурация, как она стабилизируется, а так же что такое базовые конфигурации — baselines.

В этой заметке речь пойдет о том, что большинство называют bugtracking systems. Мы посмотрим на этот класс задач и инструментов с более обобщенной точки зрения.

Мистер Томпкинс — человек уже довольно приличного возраста. Первое знакомство с ним состоялось в далеком 1938 году, когда физик и одессит Георгий Антонович Гамов опубликовал в Британском журнале Discovery серию рассказов о человеке, который в своих снах попадал в альтернативные миры, где значения физических констант радикально отличаются от значений оных в реальном мире, что приводит к совершенно неожиданным результатам. Так Гамов популярно объяснял концепции современной физики неискушенному читателю. Незадачиливым же соней был тот самый Мистер Томпкинс.

Практически 60 лет спустя Том ДеМарко решил поделиться свой безграничной мудростью и в столь же популярной форме преподнести идеи из Peopleware, написанной в соавторстве с Тимоти Листером. Итогом стал "Роман об управлении проектами", в котором наш старый знакомый Мистер Томпкинс похищается сексапильной брюнеткой Лаксой Хулигэн и увозится в загадочную страну Моровию, где ему представляется возможность провести настоящий эксперимент по управлению проектами разработки программного обеспечения…

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

Процесс автоматизации и внедрения АСУ крайне необходим. Ведь вручную управлять сложными комплексами практически невозможно (взять хотя бы АЭС). Но только после крупных техногенных катастроф осознаются ошибки и просчеты при ведении проекта Автоматизации.
Сегодня появились сведения, что перевод управления Саяно-Шушенской ГЭС в автоматический режим с 2006 г. осуществляла организация НПФ «Ракурс».
Подробнее см. статьи:
1. АСУ ТП гидрогенератора Саяно-Шушенской ГЭС — 16.01.2007;
2. «Ракурс» автоматизирует Саяно-Шушенскую ГЭС — 11.04.2007;
3. «Ракурс» модернизировал АСУТП Шушенской ГЭС — 05.09.2007;
4. НПФ «Ракурс» внедрил «ПТК ЭГР» на Саяно-Шушенской ГЭС — 12.09.2007.
Конечно всех ситуаций просчитать не возможно, но мне так думается, что автоматизацией крупных Электростанций, в частности ядерных, занимались в СССР еще 30 лет назад и за это время можно было накопить достаточно опыта в этой области.
А на поверку оказалось, что установленная АСУ на Саяно-Шушенской ГЭС если не привела к аварии, то очевидно оказалась совершенно беспомощной в аварийной ситуации:(
При возникновении аварийной ситуации одна из главных функций АСУ ГЭС это своевременное перекрытие затворов и ликвидация доступа воды на роторы и в машинный зал!
Чего АСУ на Саяно-Шушенской ГЭС не выполнила и аварийно-ремонтные затворы на водоводах гидроагрегатов были закрыты вручную. И только через 1 час после начала аварии был прекращен доступ воды в машинный зал с верхнего бъефа — см.: «Авария на Саяно-Шушенской ГЭС (2009)»:(

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

Ниже речь пойдет о следующих вещах:
— Рабочие продукты и конфигурации;
— Компонентная разработка;
— Продуктовые линейки;
— Стабилизация результатов работы;
— Baselines AKA базовые конфигурации;
— Конфигурации при компонентной разработке;
— Конфигурации при наличии продуктовых линеек.