Погрязли в делах? Возможно у меня есть метод, который может помочь. Его придумали до меня и применяется он очень широко в IT отрасли, а также всеми проект-менеджерами.и даже в Сбербанке(то-то они так рванули). И имя этому методу - Agile management - по-русски гибкое управление.
Большинство людей решают свои задачи каскадным путём, начиная и заканчивая проект 1, переходят ко второму проекту, а может уже и третьему, после чего всплывают вопросы по первому и второму проекту и мы вынуждены переходить в режим многозадачности.
Айтишники смогли обнаружить принципиально иной подход к управлению проектами, но для начала мы должны научиться разбивать каждый проект на множество маленьких этапов и научиться работать с заказчиком вплотную.
Представим что у вас 3 проекта. Каждый проект можно разбить на этапы: сбор информации - исходных данных, аналитика и обработка полученных данных, выработка рабочих решений, внедрение, закрепление.
Вы решили не распыляться и не терять концентрацию, поэтому решили взяться за один проект с самого начала и довести его до ума. Хорошее решение, учитывая мои доводы в предыдущем посте. Прошли все этапы от и до и передали заказчику.
Вы с чистой совестью принимаетесь за второй проект вам, вам сопутствует удача и вы набрав хороший темп быстро закончили и второй проект.
И вот вы принялись за третий проект, тут объявляется заказчик первого проекта и заявляет, что всё не так и надо переделать. Ваше настроение начинает портиться, но следом за ним приходит недовольный заказчик второго проекта и просит ему исправить 23 пункта.
И вот вы сидите за компьютером, настроение окончательно испорчено, третий проект завис на середине, первый и второй надо исправлять, руки опускаются, из-за плохого настроения дело продвигается медленно, так как в фоновом режиме вы прокручиваете неприятные моменты с первыми двумя заказчиками и злитесь на весь мир, в том числе на себя.
Тут звонит третий заказчик спрашивая всё ли идёт в срок, вы не знаете, что ответить, ведь вы уже заявили, что принялись за проект и назвали ожидаемые сроки.
Упс, мозг перегружается и перед глазами "синий экран - fatal error".
Что-то пошло не так.
Давайте откатимся назад, в самое начало.
Мы принялись за сбор информации первого проекта, анализируем и делаем набросок решения. Мы не приступаем к созданию готового решения и внедрению, мы отсылаем "полуфабрикат" заказчику и просим сделать замечания, для ускорения звоним ему лично и просим как можно раньше дать ответ с замечаниями.
Мы получаем ответ от заказчика, оказалось половина того, что вы собирались сделать заказчику уже не нужна, а в оставшейся половине надо сделать чуть по-другому. Быстренько исправляем, отсылаем вновь, вновь звоним и торопим клиента с замечаниями. Получаем фидбек, оказывается надо еще добавить пункты А, Б, В. Добавляем, отправляем, получаем утвердительный ответ. Ура, мы не делали пустую работу по ненужной половине, мы вовремя узнали, что надо исправить во второй половине и добавили пункты А, Б, В на предварительном этапе. Благодаря чему сэкономили время, плюс выяснили заранее, что исправить и добавить, так что все эти данные будут изначально заложены в логике и архитектуре проекта. Ведь если бы мы узнали об этом уже после того как отправили готовый проект, то после правок от клиента, нам пришлось бы начинать всё с самого начала, так как правки противоречили бы изначальной логике и архитектуре проекта.
Теперь можно смело приступать к выработке рабочих решений, внедрению и закреплению.
Уффф, с чистой совестью приступаете с тем же подходом и ко второму проекту. Тут вам звонит первый заказчик, вы с мыслью, - "Ну что теперь?", - берёте трубку и, слышите, - "Отлично сработано, в следующий раз прямиком к вам обратимся".
Занавес.
Первый метод приведённый выше называют каскадным. Он плох тем, что многие ошибки и недочёты вскрываются на конечном этапе, когда уже заложена архитектура проекта. Вскрытые ошибки могут полностью разрушить заложенную логику.
Второй вариант применяют в Agile managent, он характеризуется разбивкой проекта на маленькие этапы, и короткими итерациями-забегами, после каждого из которых, условный хозяин-заказчик, оценивает пройденный этап, вносит правки и задает нужное ему направление. В таком случае у проекта закладывается изначально правильный крепкий фундамент и переделывать приходится в итоге меньший объём работ.
Идея Agile в проектном управлении, мне кажется, также заимствована у Годратта - "Цель - процесс непрерывного совершенствования".
Идея в том, чтобы вовремя обнаружить брак и не позволять "бракованному изделию" пройти последующие этапы обработки. В противном случае компания потратит лишнее время и деньги на то, что уже бракованное.
В IT это очень важно, так как позволяет экономить много времени, не тратя его на то, что уже "бракованное", благодаря чему вы выпускаете "актуальный товар". В каскадном управлении вы можете после всех переделок в итоге получить товар, который уже не нужен рынку, так как более не актуален.
Какие вы можете встретить трудности при переходе на Agile? Во-первых, нежелание заказчика работать вплотную. Как вы будете улаживать этот вопрос - ваша компетенция. Можно попробовать просто и доступно объяснить выгоды такого подхода, так как он на самом деле выгоден обеим сторонам. Можно попробовать работать кнутом в виде повышенной расценки при использовании каскадного метода. Можно пойти путём пряника и дать какие-то бонусы клиенту при переходе на Agile, которые вам обошлись бы в низкую себестоимость, а для клиента ценность была бы намного выше.
Вторая трудность - ваша собственная неспособность разбивать все процессы на маленькие этапы и отсутствие внутренней решимости перейти на управленческий стиль Agile.
Фотографы, например, могли бы отправлять фотографии заказчику кусочками и спрашивать, что нравится или нет, но ежедневно строго определённое минимальное количество. Клиенту может не понравиться каждый день сидеть и вносить правки. Но вы можете дать бонусом бесплатно красиво украшенный альбом. Хотя многим наоборот это может понравиться, так как в таком случае они уверены, что работа не заброшена и постоянно ведётся, можно отследить на каком этапе процесс и рассчитывать к какому времени работа будет завершена.