Рубрика «управление проектами и командой» - 9

VII РАЗРАБОТКА ПЛАНА РЕАЛИЗАЦИИ И ВНЕДРЕНИЯ ПРОЕКТНОГО РЕШЕНИЯ

Блестящим планам везет на проектировщиков.
Скверным планам везет на исполнителей.
Веслав Брудзинский.

На этом этапе процесс вновь начинает крутиться вокруг руководителя проекта. Снова оценка трудоемкости, определение сроков, согласование объемов, утверждение порядка исполнения и т.п.

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

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

V РАЗРАБОТКА ПЛАНА-ГРАФИКА ПРОЕКТНЫХ РАБОТ

Чтобы выполнить большой и важный труд, необходимы две вещи:
ясный план и ограниченное время.
Элберт Хаббард

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

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

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

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

Производство информационных систем. Часть 2. Формирование проектного решения - 1
Читать полностью »

I ВСТУПЛЕНИЕ

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

Просматривая статьи, посвященные той или иной теме, связанной с созданием программного обеспечения, часто наблюдаю, вот какую картину: узкая тема раскрыта интересно и профессионально, но вот когда задеваются нюансы на стыке, по ту сторону от основного вопроса, чувствуются рассогласованность и провалы в общем понимании процесса производства информационных систем. Разрываются причинно-следственные связи. Иногда, непонимание внешнего окружения обсуждаемого вопроса, вносит искажения в основную тему, ну или по крайней мере, затушевывает некоторые важные моменты, достойные внимания. Когда же вступаешь с автором в полемику, становится очевидным, что для него вопросы, выходящие за рамки его наблюдений и опыта, абсолютно неважны. Он просто упомянул всуе сопредельную тему, а дальше, как говорится, уже не его проблемы. Второй нюанс, на котором я хочу заострить внимание – пренебрежение масштабами замысла. Ведь то, что хорошо для реализации малых проектов, смерть для больших и наоборот. Этот факт часто попросту сбрасывается авторами со счетов. А в результате идут баталии с критиками решения, в которых каждый как бы и прав, но только с точки зрения своей отдельностоящей колокольни. Сами же точки зрения никак не обозначаются сторонами дискуссии, а потому никак не учитываются.

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

image

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

Книга Элияху Голдратта «Цель» подсказывает, что пропускная способность такой системы труб будет стремиться к пропускной способности самого узкого места. Другими словами, вы могли не искать трубы пошире — если в системе есть участок с диаметром 2 см., весь водопровод будет работать как труба в 2 сантиметра.

Как этот принцип помогает зарабатывать больше? Сейчас расскажу.
Читать полностью »

Переход из тестировщика в руководители проектов - 1

Обычно на должность руководителя проектов в IT-компании требуются люди с опытом от 1 года. Поэтому часто неопытные менеджеры устраиваются на работу аналитиками, тестировщиками, иногда даже разработчиками.

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

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

Читать полностью »

Чтобы сисадмин справлялся со своей работой благодаря, а не вопреки помощи руководства

Инструкция по применению офисного сисадмина в малом бизнесе - 1

Если вы руководитель небольшой компании в 30-100 сотрудников и вас не устраивает качество работы информационных систем, то замена системного администратора — это последнее с чего стоит начать. Первое же, что стоит сделать — это изменить ваш подход в работе с системным администратором. Глобально — вам нужно научиться помогать вашему системному администратору справляться со своими обязанностями.

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

При этом я не прошу вас настраивать сервера вместе с вашим сисадмином или вникать в особенности работы программного обеспечения. От вас требуется лишь помогать системному администратору справляться с управленческими задачами, корректно информируя, направляя, контролируя и поддерживая его в работе. Как именно это делать, читайте ниже:Читать полностью »

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

Сначала кратко методику (не все с ней работали), потом – главное, зачем ее применять.

Методика измерения

Сама методика известна давно, никакого секрета собой не представляет – это покер планирования из Scrum. Чтобы ее применять, не нужно применять весь Scrum.
Читать полностью »

Что такое бизнес-процесс и описание бизнес процесса - 1О бизнес-процессах говорят много и часто преимущественно в связи с автоматизацией бизнеса. Использую этот термин и я, в том числе, в своих статьях, посвященных CRM-системам, ERP, работе с BPMN-нотациями, IDEF0 и других инструментов, которые могут понадобиться в работе бизнес-консультанта и внедрении систем автоматизации. При этом в Рунете понятное и развернутое определение термина «бизнес-процесс» я не нашел.

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

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

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

Одна маленькая, но очень гордая ИТ фирма, работала на субподряде у “монстров” отечественной ИТ индустрии. Начинали свое сотрудничество они еще до кризиса, когда деньги особо не считали, выделяя на разработку столько, сколько нужно. Меряли на глазок, ну примерно вот столько, показывая зазор между большим и указательным пальцами, дающий понять – нужную толщину пачки денег. При таком раскладе, напрягаться с точными расчетами бюджета проекта не было особого резона. Прикинули грубо и побежали. Ошиблись, ну с кем не бывает, технологии все время меняются, заказчик толком объяснить, что ему надо не может. Главное выдержать временные сроки. Чувствуешь, что не успеваешь, привлек еще специалистов и гонишь разработку к сроку. Выходит конечно чуть дороже, но вполне работоспособная схема, всем хватало, и главное голова от проблем особо не болела.

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

Опять же, в своей массе специалисты крупных ИТ фирмах знают и умеют грамотно и эффективно верстать бюджеты, но от этого как-то уже постепенно отвыкли, за ненадобностью. Тут же надо напрягаться, как-то брать ответственность, возиться с нюансами, держать руку на пульсе и реагировать, реагировать и реагировать. Короче держать себя и других все время в тонусе. Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js