Я пою то, что вижу.

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

> 90% сотрудников будет как минимум поддерживать это внедрение.

Наверное вы работаете в Раю ;)) Все коллективы где я работал достаточно неоднородны.

Может быть, поддержка на словах и была бы, но действовать точно люди не хотят.

Фактически все взаимосвязанно и влияет друг на друга.

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

Уход ключевых людей ВСЕГДА убивает процесс. Руководство компании должно это осознавать. И выбирать между:
а) экономия на процессе и количестве людей, но большой риск при уходе ключевых людей,
б) постоянное “выравнивание” всех сотрудников за счет уменьшения доходной части производства, увеличения штата и развития процесса.
Идеальных компаний не существует

> Суммарно. Получается, что решение накопление информации- либо личная инициатива нескольких человек, либо специальный отдел.

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

P.S. Виктор, я не понимаю вашего отношения к “процессу”, как к тому, что обязательно нужно навязывать коллективу, и обязательно будет принято “в штыки” как минимум на этапе внедрения. Это проигрышная позиция. Большинство процессов хорошо адаптируются и под специфику бизнеса компании, и под конкретных сотрудников. Просто не нужно “забивать” на дисциплину подготовки и работы по адаптации. Даже менеджмент по ISO можно внедрить так, что 90% сотрудников будет как минимум поддерживать это внедрение. Конечно, это стоит денег и занимает много времени (по сравнению с тупым навязыванием)

К консалтингу подобные рецепты применять нет смысла - это другая по своей сути деятельность, и документирование в ней the must (основа процесса).

В технической поддержке существует ITIL, и (если это действительно поддержка) “все ходы записаны”, иначе счета выставлять не получится.

Другие виды деятельности, относящиеся к IT я комментировать не берусь

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

Например, как работать(общаться) с заказчиками не укладывается в R&D.

>Рецепт №1 для маленькой компании - использовать по максимуму готовые и (что важно) >проверенные другими решения для построения своих продуктов.

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

>Рецепт №2 для маленькой компании - сконцентрировать накопление знаний в руках >одного-двух людей, которые ХОТЯТ, УМЕЮТ и СТРЕМЯТСЯ формализовать, упорядочить и >самое главное добыть эти самые знания.

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

Плюс, опасно, что и так болезненный уход ключевых людей еще и убьет процесс.

>Рецепт №3 - накапливать (в R&D) только ту информацию, которую мы точно знаем, что >будем изучать, пересматривать, использовать в другой деятельности в ближайшей >перспективе (до 3 лет).

С этим полностью согласен. Прицел на ближайшие 3 года - очень верный прицел.

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

Рецепт №1 для маленькой компании - использовать по максимуму готовые и (что важно) проверенные другими решения для построения своих продуктов.
Стараться по минимуму создавать собственные сложные компоненты (писать с нуля).
Если же все же хочеться “своего, родного” - нужно выбирать между:
а) низкой прибылью (или даже убытками), но с перспективой прорыва и высоким качеством (и идти по пути больших компаний в вопросе именно этой разработки)
б) риском не сделать вообще ничего из-за низкого качества, но делать компонент/продукт быстро (и в этом случае везение и личный опыт участников команды могут сильно помочь).

Из этого рецепта следует и отношение к накоплению уникальных знаний

Рецепт №2 для маленькой компании - сконцентрировать накопление знаний в руках одного-двух людей, которые ХОТЯТ, УМЕЮТ и СТРЕМЯТСЯ формализовать, упорядочить и самое главное добыть эти самые знания. Всем остальным объяснить/приказать/упросить помочь этим людям своими ОТВЕТАМИ на их уточняющие вопросы, и регулярным рецензированием их трудов.
Ежели… ежели нет таких людей в компании, то и рыпаться не имеет смысла, особенно всем вместе в “дружном порыве”

P.S. У нас в компании тоже много “запущенных” мест, кода и проектов Но есть 2 человека, которые эту ситуацию понемногу исправляют.

Рецепт №3 - накапливать (в R&D) только ту информацию, которую мы точно знаем, что будем изучать, пересматривать, использовать в другой деятельности в ближайшей перспективе (до 3 лет). Если знаем, что это “на перспективу”, но конкретно куда и когда пойдут знания непонятно - не стоит над ними и задумываться

Основные случаи повторного применения:
1. Пришел новый человек в компанию.
2. Пришел новый человек в R&D.
3. Пришел новый человек в проектную группу (занимающуюся разработкой по одному-двум направлениям).
4. Существует “костыль”, который всем мешает, но еще год будет работать (не больше). Решили от него избавиться.
5. Запланирована (на конкретную дату) смена платформы для нескольких компонентов/продуктов. Необходимо подготовиться.
6. Компания вышла на новый рынок, либо значительно расширила свое участие на существующем рынке.
7. Компания выпустила успешный продукт, и его хочет выкупить вместе со знанимя и людьми большая корпорация.

В каждом из этих случаев НЕОБХОДИМО пересмотреть накопленные знания, произвести их “чистку” и четко обозначить пробелы.
В случаях 6 и 7 знания можно оформить книгой, и даже неплохо на ней заработать.
В случаях 1 и 2 - внутренним справочным руководством (в виде книги - идеально)

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

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

>Главное — это процесс, привычки, а не мотивы. Бизнес-знание должно быть >встроено в работу.

Я согласен. Даже продолжу мысль. Идеально, если без процесса работать становится сложнее и тяжелее.

Некоторые мысли in no particular order:

* Больше документации — не значит лучше, чем ее больше, тем меньше будут ее читать, тем больше сил будет уходить на ее написание и поддержку. У меня есть старенький iPod Shuffle, так вот, у него замечательный user manual. Он занимает ровно одну пластиковую карточку. Там есть и другой побольше, но он типа для редких случаев установки или troubleshooting’а. Эта карточка просто чудо в сравнении с теми кошмарными простынями или талмудами на всех языках, которые обычно идут к технике.

* Печатная документация недорогая, но трудная — читать тяжело, особенно типичный канцелярский стиль. И люди вообще в целом постепенно перестают читать. А хорошая документация с графикой, аудио, видео пока еще дорогая. Хотя можно найти и компромисные решения, вроде скринкаста.

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

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