Pull to refresh

Comments 10

Вот не поверите, только сегодня размышлял о том, что пора уже написать о том, что нужно отделять мух от котлет управление производством от управления проектами. Тогда снимается львиная доля проблем и сложностей.
Хорошо, но тогда надо организовать понятный интерфейс между этими слоями. А в условиях, когда все слишком заняты…
По моему опыту, сложности возникают всегда при попытке синхронизировать изменения между средством управления задачами (TFS, Jira, Redmine, Trac и т.п.) и инструментом управления проектом (как правило — Project, но может быть и Excel или даже бумажный лист). Ключевое слово — «приходится». Все эти сложности как бы намекают, что копаем не там где надо. И, хотя менеджерам, которые выросли из программистов (сам таким был) такая функция кажется очевидной, на самом деле ниоткуда не следует, что управление проектом и управление задачами работают в одних и тех же терминах.
Даже программы мы давно уже не пишутся ассемблере, для этого используются языки высокого уровня, которые, конечно, не дают возможностей управления на уровне регистров, но внятно говорят машине чего мы от неё хотим.

Так вот, к чему это я. Модель проекта, с которой работает менеджер и модель задач, с которой работают разработчики — это разные вещи и между ними не всегда возможна автоматическая синхронизация. Дажа, я бы сказал, она вредна. Проект включает в себя много факторов, и программирование — это только малая часть, далеко не всегда самая трудоемкая. А «интерфейс между слоями» — это совместная работа менеджера проекта, тимлида, аналитика и других заинтересованных лиц. Потому что слоёв не два, а гораздо больше.
Ну, если средств нет, это ещё не означает, что это именно потому, что их в принципе быть не может. Того же Project'а и Excel'а тоже когда-то не было. Или более подходящий пример: не так давно фейсбука не было, а люди как-то между собой общались. Может быть, стоит отказаться от него сейчас? Мне кажется, нам, технарям вредно думать в направлении, что что-то сделать нельзя. Целесообразность создания средства может быть под вопросом. Но мне не так много не хватило в связке Project + TFS.

Согласен с тем, что высокоуровневые проектные задачи и таски — это разные вещи. Не уверен, что это подчёркнуто в статье, но я это имел в виду, когда её писал.

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

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

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

Есть контр-аргументы создания такой системы. Проблемы делятся на две группы:
1) Проектные подходы различаются, поэтому сделать систему, которая учитывает все нюансы, довольно трудозатратно
2) Люди — это не ресурсы, а именно люди — и им тяжело выдерживать до конца тот цикл, в который их стараются погрузить

На мой взгляд, совершенно очевидно то, что машину несложно научить исправлять ошибки планирования вида «таск X стала в два раза дольше, поэтому есть проблемы с закрытием итерации => существует риск закрытия этапа». Но программисты очень мало инвестируют в технологии для самих себя. С их точки зрения это очень длинные инвестиции, а текущая разработка принесёт прибыль здесь и сейчас. Именно по этой причине в статье я и обратился с критикой к гиганту — Microsoft — ведь у них есть система для управления проектами и система для управления разработкой. Microsoft до сих пор качественно их не объединила, но при этом затраты на «рутинный труд менеджеров» у них самих при выпуске продуктов должны быть грандиозными. Те же новости о срывах сроков производства Windows и Office появляются регулярно.
А вот тут ответ очень простой. Средства вполне могут быть. Но средства сами по себе никакую проблему не решают. Проблему (теоретически) смогут решить люди, которые эти средства будут использовать. Чтобы проблемы решались, эти люди должны уметь и понимать довольно много разных полезных вещей и еще больше делать. Чтобы был заметный эффект, потребуется не только система, которая что-то там умеет делать, но и реальное изменение в подходах к работе. Эти изменения коснутся не только менеджеров, но и программистов и руководителей. Людей способных и желающих провернуть подобные изменения в своих организациях слишком мало, чтобы сформировать рынок, который бы окупил создание подобной системы.
Microsoft при первом релизе TFS запилили примитивную интеграцию TFS с Project, этим мало кто воспользовался — они и не стали развивать. Ничего личного. Просто бизнес.
И еще, забыл написать почему вредно :)
Вредно, если кратко — потому что борьба с ветряными мельницами непродуктивна. Если все засинхронизировать, все планы будут прозрачно перетекать и обновляться, то возникнет ложное ощущение того, что все под контролем. А в управлении проектом, повторюсь, задачи разработки — они даже не на втором плане по важности. Отсутствие такой прозрачной автоматизации в мелочах порождает необходимость немножко поработать головой и руками. Мозг не умеет работать с большим количеством мелких артефактов, приходится их обобщать. А это помогает расширить угол зрения.
С этим согласен. Вопрос — в проработке взаимосвязи. Можно и нужно сделать лучше.
Давно уже об этом (здесь и не только) твержу :)

И да, статья весьма хороша.
Ничего не предлагает.

Всю жизнь в таких ситуациях выкручивался базовыми планами.
Спасибо! :)
Не совсем, правда, понял, как вы выкручивались базовыми планами… уточните?
Хорошо бы еще добавить, сколько стоит то или иное решение в пересчете на одно рабочее место (или на группу из N).
И кстати, есть еще IBM Rational Team Concert.
Sign up to leave a comment.