[Тимур]

И еще раз, здравствуйте. У меня опять дурной вопрос :-)

 

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

Ну то есть... ведутся какие-то дела, принимаются какие-то решения, какие-то встречи. То есть вроде как все заняты. Вон... даже пофлудить в "прямой трансляции" - времени нет :-))

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

 

Для сравнения - я, например, могу, посмотреть в СРМ, и за десять минут понять картину происходящего. Понятно почему - ключевые бизнеспроцессы набиты, хорошо автоматизированы и нормированы. Учетные точки понятны. С проектами не так. Хотя мы их вроде даже регистрируем в системе учета дел.

 

Фундаментальные отличия проектов от стандартных бизнеспроцессов типа "заявок на подключение" таковы

 

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

- на проекты нет единых стандартов времени. То есть задача может быть и дневного уровня и двухгодового, допустим

- проекты крайне легко ветвятся на подпроекты

- в отличии от типизированных задач у проектов далеко не всегда есть ярко выраженная ценность

- проекты нормально ставить на паузу, или даже сливать

- есть довольно большая неоднозначность в приоритетах

 

 

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

 

- как увидеть картину в целом.

 

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

 

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

[zadrovets]

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

Вы попробуйте, только по настоящему.

[vsn]

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

Вы попробуйте, только по настоящему.

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

[HelgS]

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

Ответственным за проекты пробовали это озвучивать? Неужели они только и делают что успокаивают ничего не предлагая?

[Mikler]

Проджект только начало пути. При достаточной сложности проекта нить опять утрачивается. Лучше смотреть в сторону систем с понятной общей шкалой. Например Redmine. Понятная шкала проекта начальство писается от радости о том, что вот он график и вот оно завершение в процентах. Детально можно рассмотреть кто, что сделал и какие задачи препятствуют завершению. Сгенерировать отчеты. И так далее. А вообще это классика жанра управления проектами. Наверно надо начать с PMBOOK. Где то встречал краткий курс PMBOOK за 5 дней. Там по шагам описывается, что за чем следует и как проводить собственно мониторинг этого безобразия, некая систиматизация общих подходов. У вас сейчас стоит задача мониторинга исполнения, и закрытие проекта с успешными результатами. Что то изменить координально не сильно получится. На стадии инициации проекта вы уже определили цели задачи, документация по управлению проектам не стояла в задачах, будет разброд шатание и снижение эффективности.

[Barbaris]

... Наверно надо начать с PMBOOK. Где то встречал краткий курс PMBOOK за 5 дней. ...

Не соглашусь.

[Barbaris]

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

Хороший инструмент.

Однако, не уверен, что Тимура главная проблема - выбор инструмента.

Изменено 4 июля, 2012 пользователем Barbaris

[Прохожий]

http://www.tutos.org/

 

Но без понимания принципов проектного управления - никакой инструмент не поможет.

[Barcha]

Тимур, потрать время и деньги, сходи на specialist.ru и поищи курс "Менеджер проектов", все встанет на свои места =)

[Barbaris]

все встанет на свои места =)

Не встанет.

[AlexBT]

Автоматиировать бардак нельзя. Так же и управлять проектом бардака невозможно.

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

 

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

 

 

 

[Diesel]

Мы достаточно долго пользовались http://www.advanta-group.ru/

Плюсы - наглядность, понятность и масштабируемость.

Минусы - мы сами не довели дело до конца.

Самый страшный враг внедрения таких систем - это хреновые сотрудники. Их хреновость моментально становится видна, и они любыми методами пытаются саботировать внедрение. Тут надо быть готовым идти до конца. Нет дела = нет ЗП. Мы не смогли, сломались на этом этапе :-(

Думаю будем повторно пробовать.

[Barbaris]

...Самый страшный враг внедрения таких систем - это хреновые сотрудники. ...

Супер! Заношу в личный цитатник :)

[Mikler]

Мы достаточно долго пользовались http://www.advanta-group.ru/

Плюсы - наглядность, понятность и масштабируемость.

Минусы - мы сами не довели дело до конца.

Самый страшный враг внедрения таких систем - это хреновые сотрудники. Их хреновость моментально становится видна, и они любыми методами пытаются саботировать внедрение. Тут надо быть готовым идти до конца. Нет дела = нет ЗП. Мы не смогли, сломались на этом этапе :-(

Думаю будем повторно пробовать.

Как то не очень понятно. Какой прок от людей которые ничего не делают? Почему вы с ними не расстались? Или это дети руководства были :))) ?

Изменено 16 июля, 2012 пользователем Mikler

[Прохожий]

Как то не очень понятно. Какой прок от людей которые ничего не делают? Почему вы с ними не расстались? Или это дети руководства были :))) ?

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

 

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

[izuware]

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

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

[Прохожий]

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

Да не надо делить ;)

Одна из навязчивых управленческих идей - это "участие в прибыли", т.е. разнесение финансовых результатов на весь коллектив. Бывает удачно имплементирована, но чаще - полный факап.

 

Все гораздо проще, три шага:

1. Придумать как измерить качество работы. Метрика может быть ЛЮБАЯ, лишь бы она была измеримой любым способом, хотя бы в виде да/нет

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

3. Привязать первое к желаемому значение второго.

 

Дальше остается придерживаться принятой концепции невзирая на.

 

Самый простой пример, метрики монтажника по подключению:

1. Число выполненных заявок (при наличии ситуации "перегрузки" заявками, при наличии "простоев" у подключал нельзя их карать за то, что не делают работу, которой нет!)

2. Средняя оценка его работы абонентом по данным постконтроля

3. Число претензий клиента, признанных обоснованными

 

Эти три параметра сводятся в простые правила изменения ежемесячной переменной части от нуля до 100%. После чего все претензии на "несправедливость" тупо отправляются в dev/null. Если система окажется логичной и позволит зарабатывать человеку, который работает - она взбодрит. Если будут допущены серьезные ошибки - монтажники просто разбегутся как тараканы. Но это - обычные управленческие риски ;)

 

что становится невыгодно писать отчеты

Отчеты - абсолютное зло. Их быть просто не должно. Информация о результатах функции должна быть объективно отделена от исполнителя функции и видится им в одном разрезе с начальством ;)

[izuware]

Отчеты - абсолютное зло. Их быть просто не должно.

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

[Прохожий]

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

Если нет другого способа внести - значит надо придумать как независимым образом проверить. Иначе Вам навносят ;)

[Mikler]

Отчет бессмысленный и беспощадный :)

[izuware]

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

Если нет другого способа внести - значит надо придумать как независимым образом проверить. Иначе Вам навносят ;)

ктобы придумал, а пока ВилкамТуСтароеРусло и контроль качества работ по интонациям в телефоне :)

[Тимур]

Самый простой пример, метрики монтажника по подключению:

1. Число выполненных заявок (при наличии ситуации "перегрузки" заявками, при наличии "простоев" у подключал нельзя их карать за то, что не делают работу, которой нет!)

2. Средняя оценка его работы абонентом по данным постконтроля

3. Число претензий клиента, признанных обоснованными

 

С монтажниками или там менеджерами по продажам, простите, не интересно. Вы расскажите как метрить программистов. Или скажем руководителя абонентского отдела.

[HelgS]

Вы расскажите как метрить программистов. Или скажем руководителя абонентского отдела.

Оценка количества и качества закоммиченного кода руководителем программистов.

Анкетирование сотрудников абонентского отдела, опрос клиентов, оценка деятельности от смежных отделов.

[Gull]

Оценка количества и качества закоммиченного кода руководителем программистов.

 

Это на уровне нравится - не нравится.

[Mikler]

Есть roadmap туда входит фиксированное количество фич, багов и прочего. Оцениваем сроки выполнения с участием команды. Смотрим сколько сделали, сколько пофиксили. И так несколько периодов. Результаты и оценки на лице. Поощряем непричастных, наказываем невиновных. Следующая итерация будет с большим интузазизмом.