
Меня долго занимал один вопрос. Почему внедрение средств управления проектов в России сложнее, чем на западе? Недавно я понял, что причина в неструктурированности понятия проектной организации, в отличие от других видов компаний. Чтобы понять роль инструментов «ведения проектов» и «сотрудничества в проектах» (collaboration tools) достаточно понять место проекта в организации. Как выглядит идеальная структура проектно-ориентированной организации?  Структура проектной организацииКогда основным процессом производства являются проекты, то каждый проект, как живой организм, включен в более широкий контекст компании. В этом «широком» контексте можно выделить: - CRM и продажи
- Финансовая поддержка проектов
- Юридическая поддержка проектов
- HR, служба персонала
- Ведение «рабочей среды», environment. То, чем занимается офис-менеджер
- IT-служба, основная цель которой в данном случае - продуктивность проектов.
- Общение с подрядчиками, аутсорсинг, фрилансеры
- Общение с клиентами
Естественно, каждая компания в свою очередь включена в намного больший контекст государства, рынков и других элементов. Мы их не будем рассматривать. Проект - это командаИтак, внутренняя структура проекта - это его команда. Команда состоит из - Экспертов
- Поддерживающего персонала
- Менеджера проекта
Эксперты - это основная движущая сила проекта. Собственно, те, которые вкладывают свои знания и усилия для создания продукта. Это могут быть программисты, архитекторы, маркетологи, консультанты, в зависимости от отрасли бизнеса. Поддерживающий персонал это те люди, которые делают всю работу, без которой основной продукт «экспертов» нельзя назвать товаром и продать. В разработке ПО, например, это тестировщики или технические писатели. В организациях с матричной структурой как эксперты, так и поддерживающий персонал зачастую заняты, кроме конкретных проектов еще и в «поддерживающей» деятельности бизнеса. То есть участвуют и в проектах, и в операционной деятельности всей компании. Так каково же место систем поддержки проектного процесса? Это - взаимодействия «внутреннего» круга проекта между собой
- управление проектом
- минимально необходимые взаимодействия с «внешним» кругом
Наиболее важны отношения с клиентом и подрядчиками, вплоть до включения их в команду проекта (в случае customer on-side или фриланса). Поэтому соединения с этими двумя «внешними» секторами обычно становятся частью самого проекта. Цели внедрения отдельной системы для ведения проектов очевидны. Это максимальное использование потенциала команды и фокусирование их на одной цели. Увеличение производительности, скорости и качества проектов. За счет использования как инструментов общения, так и методологий управления проектами. Сложности в головеВозвращаясь к основному вопросу. В чем же сложность внедрения? Сложность в том, что зачастую в системы ведения проектов стараются «впихнуть» и обслуживание внешнего круга, то есть задачи любого из поддерживающих направлений. Это естественно, ведь стандарты автоматизации существуют на данный момент только для финансов, и частично для CRM / продаж. Таким образом, инструменты ведения проектов используются для процессов не внутри проектов. Какие именно «мостики» должны соединять систему ведения проектов, и внешние службы? Обычно это соединение или в форме «контактов» от отдела продаж, или «инцидентов» для офис-менеджера, или «отчетов» для финансового отдела и HR. Это возможно, но разделение «проекты - службы» должно быть понятно хотя бы руководителем при решении о внедрении системы. И тогда можно ответить на вопрос, что же именно стоит автоматизировать в первую очередь. И как все связать в интегрированную среду.

ИдеологияХотя есть, наверное, сотни разных подходов к форматированию Вики: традиционные вики-системы, корпоративные вики - мы сфокусировались на использовании наиболее распространенного формата MediaWiki, который, в частности, используется на Википедии. Знание синтаксиса Вики - это хороший плюс при использовании Comindwork, так как в системе не везде показывается визуальный редактор. Например, нет для него места в комментариях к блогу или к документу. Но иногда ведь нужно вставить картинку или ссылку, или просто улучшить внешний вид текста. Приведем другой пример полезности режима редактирования вики-разметки. Допустим, понадобилось создать список, состоящий из множества почти одинаковых ссылок. В визуальном редакторе придется вставлять каждую ссылку по отдельности через диалоговое окно. Вместо этого можно переключить редактор в режим вики-разметки, скопировать код ссылки, который послужит шаблоном, в буфер обмена, вставить этот код нужное количество раз, а затем во вставленное внести необходимые мелкие исправления. Общие правила- MediaWiki - http://meta.wikimedia.org/wiki/Help:Editing
- В отличие от MediaWiki вы в Comindwork можете также использовать HTML, нет никаких ограничений.
- В MediaWiki абзацы отделяются "двойным переносом строк", в Comindwork абзац создается по единичному переносу
Основные стилиСтрочные стили| Название | Пример | Код |
|---|
| Жирный | bold | '''bold''' | | Наклонный | italic | ''italic'' | | Подчеркивание | underlined | __underlined__ | | Помните, что вы можете вводить HTML-тэги, например 'sub или 'strike' |
| Заголовки| Название | Пример | Код |
|---|
| Заголовок 1 | Head 1 | = Head 1 = | | Заголовок 2 | Head 2 | == Head 2 == | | Заголовок 3 | Head 3 | === Head 3 === | | Заголовок 4 | Head 4 | ==== Head 4 ==== | | Заголовок 5 | Head 5 | ===== Head 5 ===== |
|
Форматирование абзацев: списки и отступы| Название | Пример | Код | | Цитата | TEXT | <blockquote>TEXT</blockquote> | | Отступ | ident | начните строку с символа(ов) ":" | | Нумерованный список | - Number1
- Number1
| # Number 1 ## Number 1 | | Ненумерованный список | | * Number 1 ** Number 2 |
Ссылки Красный цвет ссылок означает, что ссылка ведет на несуществующую страницу, файл, задачу и т.д. Вставки и специфичные возможностиВставка картинокЧтобы вставить картинку в текст, - залейте ее в файловое хранилище
- используйте {{\\Path\To\YourImage.jpg}} (заметьте два символа \ перед началом пути). Пример:
{{\\COMINDWORK/FILE/Hypnotoad.jpg}} - Подсказка: если вы добавили файл с пробелами в имени, пожалуйста, в ссылке на него замените пробел на %20
Вставка страницВставка страниц это мощный механизм для создания навигации в страницах проекта. Например, когда вы струкурируете требования, вы можете, кроме использования меток, добавить вверху страницы "управляющий" блок. Чтобы вставить другую страницу или документ: - используйте {{PROJECT/PAGENAME}}
- Подсказка: Чтобы спрятать часть страницы при вставке, используйте тэг
<noinclude> этот текст будет спрятан </noinclude> Выключение Wiki-форматированияВы можете захотеть выключить форматирование Вики для какой-либо части текста. Вы можете это сделать таким вот образом: <nowiki>Тут какой-то странный текст</nowiki>

IdeologyAlthough there are tons of different wiki formatting approaches (traditional wikis, various enterprise systems etc) - we focused on use the most widespread formatting provided by MediaWiki and adopted by the most popular wiki-based resource WikiPedia. Knowing Wiki syntax is a good plus, as we don't show rich editor at any wiki text box, like blog comments or wiki page comments. But sometimes you may want to enter a link in comment or enhance your formatting. General rules- MediaWiki - http://meta.wikimedia.org/wiki/Help:Editing
- Unlike MediaWiki you can use HTML as well in Comindwork Wiki, no limitations are applied.
- MediaWiki has paragraphs created by "double enter", Comindwork also creates BR-tag for "single enter"
Main StylesInline styles| Name | Sample | Code |
|---|
| Bold | bold | '''bold''' | | Italic | italic | ''italic'' | | Underlined | underlined | __underlined__ | | Remember you may enter pure HTML tags, like 'span' or 'strike' |
| Headings 1-5| Name | Sample | Code |
|---|
| Heading 1 | Head 1 | = Head 1 = | | Heading 2 | Head 2 | == Head 2 == | | Heading 3 | Head 3 | === Head 3 === | | Heading 4 | Head 4 | ==== Head 4 ==== | | Heading 5 | Head 5 | ===== Head 5 ===== |
|
Paragraph-formatting: Lists and Indent | Name | Sample | Code | | Identation | :ident | start new lines with ":" sign | | Numbered list | - Number1
- Number1
| # Number 1 ## Number 1 | | Unnumbered list | | * Number 1 ** Number 2 | Links Please note that red color means link to not-existing page or case. Includes and special issuesIncluding imagesTo insert an image on a page, - upload it to filesystem
- use {{\\Path\To\YourImage.jpg}} (Note the 2 slashes before actual location)
- TIP: if you've uploaded file with spaces in name, please refer to it, replacing spaces with %20
Including pagesIncluding pages is a powerful mechanism for creating TOC-pages or navigation snippets to other pages. For example, when structuring project requirements, you may want to put navigation to to the top of every requirements-related page. To insert an page: - use {{PROJECT/PAGENAME}}
- TIP: If you're referring to a page that starts with user/default/ you may use {{:PAGENAME}}
- TIP: To hide a part of the page when including, use
<noinclude> this text will be hidden </noinclude> Switching off Wiki formatting You may need to switch off Wiki formatting for some block of text. You can do it using the following syntax: <nowiki>Strange code is here</nowiki> Useful templates | Name | Sample | Code | | Quote | TEXT | <blockquote>
TEXT
<blockquote>
| | Red | TEXT
| {{:Red|
TEXT
}}
| | Green | TEXT
| {{:Green|
TEXT
}}
| | Pretty table | This table is generated using <table {{:PrettyTable}}> |

Обычные инструменты поддержки работы (в виде любых workflow-систем, включая BPM, системы управления бизнес-процессами) дают не так много для работников умственного труда. Это происходит потому, что эти системы построены на одном и том же принципе планирования. Сначала определи задачи, раздай их, потом собери воедино результаты. То есть, сначала одна задача, потом другая, одним потоком. Иногда, к счастью работников, больше чем один поток активностей может происходить в одно время. Но обычно инструменты и обучение менеджеров диктуют нам условия: как нам делать задачи, и в каком порядке. Этот подход работает только для типов задач, которые повторяются и могут быть наполовину автоматизированы. Работая в которых, люди не допускаются до низкоуровневого принятия решений. Например, - Проверки на соответствие качеству
- Строительство
- Выпуск новых версий продукта
- Сборочные линии
- Логистика
- Бухгалтерия и счета
- Торговля ценными бумагами
Но умственная работа, точнее, ум и внимание, работает совсем по-другому. Часть задач не могут быть определены заранее и повторены механически. Скорее, каждый рабочий процесс зависим от других людей, и является процессом переговоров с коллегами. Информация должна быть собрана и проверена разнообразными способами, действия должны быть чувствительны к бизнес-окружению. В этих областях, планы зачастую постоянно меняются по ходу работ. Обычные области умственного труда, которые невозможно поддерживать с помощью инструментов "производственного процесса", это, например: - Исследования
- Разработка продукта/услуги
- Маркетинг
- Продажи сложных продуктов
- Поддержка пользовател
- Работа с партнерами
- Управление организационными изменениями
- Управление командами
- Аудит
- Внедрение стратегии/политики
- Переговоры
"Процессы, основанные на задачах, которые описывают как сделать ту или иную задачу. Эти процессы в основном регламентируются ИТ-системами и управляют "ресурсами". В то время как процессы, основанные на людях, определяют или описывают, как люди работают вместе. Обе части важны для бизнеса. Однако, они совершенно разные, и не могут одинаково хорошо поддерживаться одним набором политик и технологий" ("BPM, BKM, and the Seven Ps: Processes," Michael Dortch, Aberdeen Group,April 2007) Чтобы проиллюстрировать недостатки ПО, которое базируется исключительно на определении задач, вспомните о странной, но повсеместной трагедии современного "рабочего места". Людей нанимают за их умственные качества (способность к аналитике, стратегическое мышление, креативность и т.д.) и потом их за это штрафуют. Когда рабочие процессы будут поставлены на место, которое действительно отражает, что люди хотят сделать и достичь, менеджеры смогут заняться своей настоящей работой: поддерживать начинания сотрудников, улучшая условия их работы. Организации должны научиться использовать время и умственные усилия своих сотрудников в исследованиях, сравнении, оценке своих сил, принятии решений, и вцелом превращении информации в идеи и знания. Источник: Keith Harrison-Broninski - Human Processes

It's possible to shrink this whole post to single phrase. "Manage people, not tasks". Actually that's all. But if anything inside you tweaks when you think of this phrase, I propose to go a bit deeper. Do you agree with "Product equals team" statement? Same statement can be told more scientifically: "Project quality equals quality of development process". Well, you can agree or disagree with the last words - it's your own business. But it's the basis of all current project management science. Six Sigma, Toyota Production System, TQM - all these techniques are results of same idea, that in its strongest variant sounds as "Product equals team". Especially this is the case in knowledge-intensive organizations, where the only resource is people. From "team collaboration" up to TPS is actually not that long way. Beforehand, there was "human collaboration", which is called now Human Interactions Management. Later this idea grew into Business Process Management. So, to start building Toyota, you should start from your team. Your people. When choosing between giving a fish and providing a man with a fish rod, we tend to the second solution. When applied to team work. Instead of pre-organized set of instructions and communication formats, we push people towards people starting to make arrangements. Those arrangements then may be written down, prove their effectiveness and become "roles". This is somehow more complicated team-building process, but it leverages every single team member in mid-term and long-term. Because product equals team. As William Joyce wrote in his book " What Really Works: The 4+2 Formula for Sustained Business Success", there're 4 success factors for success: - Strategy: build strong strategy, focused on growth, and stick to it.
- Execution: organize excellent practical implementation of your strategy
- Culture: develop corporate culture, oriented on reaching high goals
- Structure: support "flat" and mobile organization structure
Two of four points relate solely to people and interactions inside the team! At the beginning of work, team builds up the process of enabling collaboration and agreements (important people qualities: creativity and trust). Later each team member works on constantly testing the format of collaboration (with full responsibility and intelligibility). And only on the third step, company agreements and process formats become a part of system, part of enterprise software. "System" comes after human collaboration, not before. That's what Agile Manifesto says: "People and interactions over processes and tools". That's exactly the idea behind Comindwork. Using basic agreements, you can create synergy in your team, which is really the essence of team work. 2+2 = 5, i.e. 4 people together do more then 4 people working separately. For steady businesses we provide custom workflows processes and tools. Which can only be working on the basement of trust, constant improvement, and responsibility of every person for both result and process of project development.
|