Мне кажется в какой-то из статей я уже задевал эту тему. Меня немного, когда пишут – компания успешно выполнила скажем 500 проектов.
Смешно это тем, что выполнили эти проекты люди, причем, которых в компании уже давным-давно нету. А если все знания о том, как делались проекты были в головах людей, что же осталось в результате у компании? А у компании толком не осталось ничего кроме заработанных денежек.
И что мы имеем? А имеем мы богача с полной амнезией. Так что же, надо писать, компания нарубила бабла за последние 500 проектов, увы мы плохо помним за какие?
Оставим хиханьки-хаханьки, и буду предельно серьезны. Это гигантская проблема, особенно для больших компаний или компаний с большой текучкой. Ведь опыт не может аккумулировать в компании, он может накопляться только в чьей-то голове. Соответственно, дай бог, если владелец и несколько менеджеров остаются и накопляют частичку опыта, а так ведь все выветривается.
Кстати, обычно переход уходом какого-то человека производят передачу дел и деление опыта. Это обычно полный ужас-ужас. Я видел единицы случаев, когда передача происходило нормально. Обычно, человеку который уходит уже все пофиг, человеку который принимает дела некогда, так как на нем и так лежат три проекта.
Я уже писал в статье, что накопление опыта, происходит только благодаря тому, что делаются ошибки, анализируются и потом делается правильно. Хитрость состоит, что если в компании спрашивают, почему был завален проект X, а люди отвечают, потому что Вася долб@еб его завалил (уже уволен). И при этом никто не может ответить конкретно, как его Вася завалил и почему так вышло и чем он собственно такой тупой это Вася, то вероятнее всего пришедший на его место Петя или Коля с таким же успехом завалит следующий проект.
http://victorronin.com/2008/04/14/opytnyj-znachit-oshibavshijsya/
Как по мне есть единственный выход из этой ситуации – это сбор и анализ корпоративных ошибок. Именно ошибок на уровне нетехнических решений, а проектных или стратегических. Чтобы данные о ошибках из головы перекочевали в некое хранилище, в котором можно было бы порыться.
Это и только это позволит компании иметь память вне людских голов.
Я опущу вопросы, какую информацию собирать и как анализировать. Для разных компаний – это будет по разному. Просто хочу сразу вскрыть основную проблему, почему фактически ни одна компания это не делает.
Сначала я опишу один пример из жизни, а потом уже вернусь, почему же никто толком не занимается корпоративной памятью.
Компания N1 (США) за свое деятельность поменяла 3 или 4 офшорных фирмы. С всеми фирмами были похожие (практически идентичные) проблемы (в большинстве своем инициированные компанией N1). Каждый переход на использование новой офшорной фирмы происходил с серьезными потерями финансов (ну скажем порядка $200-300K, при оборотах фирмы в несколько миллионов) и производительности (толком даже измерять не могу). Очередной менеджер, решил, что проблема в офшоре (и решил от него избавляться), хотя на самом деле, проблема в стратегии поведения Компании N1. Таким образом, из-за отсутствия данных, я думаю суммарно фирма прибила несколько миллионов на борьбу на самом деле с достаточно простой проблемой, то, что она толком не составляла контакт. Даже, если учесть, что достаточно сложно заставить выполнять контракт фирму находящуюся в другой стране, все равно, проблема остается в том, что нигде не были записаны/озвучены точные требования, ожидания и ограничения в работе.
Итак, возвращаясь к статье. Основная проблема с тем, почему информацию не хранят, заключается в следующем:
Почему программисты не любят писать документацию к проекту? Потому, что то, что они пишут – они и так знают, а то, что через 2-3 года кому-то придется разбираться с проектом их не слишком волнует. Получается, что для программиста написание документации выглядит как потеря времени. С другой стороны с точки зрения фирмы, это разумное вложение времени.
Тоже самое происходит и с менеджерами. Для них описания проблем, с которыми они столкнулись, как они их решали и что произошло — не имеет смысла. Так как они и так это уже знают, а то, что будет с менеджерами в фирме через 2-3 года опять же их не сильно волнует. Правда, ситуация похожа на программистов и документацию?
И точно также как с программистами – им надо объяснить и в приказном порядке заставить писать документацию, точно также надо поступать с менеджерами. Причем, точно также как кто-то должен проверять что документация написана у программистов, нужно проверять, что описаны проблемы и их решения у менеджеров.
Естественно не имеет смысла записывать каждый пук в компании. И как я уже писал, в компании может быть необходимость разного уровня информации. Важно то, чтобы когда приходил новый менеджер/директор он мог изучать компанию по уже имеющимся данным, а не опять разбираться заново и делать те же ошибки, что делались раньше.
просто программистов так обучают, что не надо писать документацию. я пришел к писанию документации на все функции и объекты самостоятельно, потому-что это даже мне самому удобно — при 3-4 проектах одновременно, через месяц уже ничего не помнишь
в этом смысле очень показателен опыт кнута, который в недавнем интервью опять рассказывал про literate programming
Насчет программистов так обучают. Я бы сказал, что программистов толком вообще не обучают. Сами заразы учатся 🙂
Вопрос состоит, в том, что делать с людьми, которые сами до этого не дошли. Точно также, как сами менеджеры не дошли до записи проблем, их решения и методик.
Проджект менеджеров тем более нигде не обучают 🙂 эти ваще как подкустовные выползни, откуда они берутся под кустом науке пока еще неизвестно.
:))) Ну, я бы уточнил. В Украине их не обучают. Хотя думаю могли уже появиться специальности на что-то похожее направленное.
В США, вполне есть специальности направленные на IT менеджмент (что в общем-то и есть product и project manager’ы).
Я как-то давно писал про понеглифы.
Название малость пафосное, но использование термина XP (как базового) внесло бы смуту.
Вообщем-то задача вполне реализуемая, было бы желание. Главное — то что реализация возможна как глобально, так и локально — например одним отделом здравомыслящих людей, или даже одним человеком из отдела (и ему не обязательно владеть какими-то полномочиями)
Я бы сказал, что это похожая, но не совсем та задача.
Похожая в смысл того, что нужно документировать. Непохожая в смысле того, что абсолютно другие входы и выходы системы.
В описанных понеглифах, вход — задача, выход документация.
Статья скорее относится к разным бизнес процессам фирме (не всегда декларируемых как задача). Например — работа с оффшор фирмой, это не задача и даже не проект, это пожалуй направление.
Плюс для разработки документация нужна всегда. Тут скорее нужна документация в определенных случаях (особо хороших или особо плохих ситуациях).
В общем, как я и говорил, похоже, но не точно та же ситуация.
Ограничение по объему комментария имеется?
Не уверен. Если есть, что-то встроенное в движок, то я об этом не знаю.
Есть ограничение по количество ссылок. После 5 они отправляется на модерацию.
По объему ограничение тоже есть, я с этим уже столкнулся. Буду делать репост последовательный с разбитием на сегменты.
Дисклеймер:
Сожалею, что не ответил раньше, хотя много чего написал и отправил.
Подготовленный пост не был принят ресурсом без регистрации, со снятым чек-боксом на уведомление по e-mail, и не сохранился, в связи с выходом из браузера. Есть ограничения в объеме? Ошибка обработчика комментариев ресурса?
Всё возможно, и всё возможно к лучшему, теперь немного добавлю деталей.
Суть:
Чтобы не возвращаться к покрывшимся налетом времени и комментариев старым постам, остановлюсь на новом: про корпоративную амнезию.
Заявка на 500 завершенных проектов в идеале должна проецироваться на общее число старт-апов, и аппелирует не столько к показателям финансовой эффективности, сколько к подходу к управлению качеством.
Агрегирование и передача накопленных знаний (lessons learned, best practices, know-how, process workflow, et cetera) осуществляется, как правило, корпоративным отделом, ведающим Quality Policy компании. Подотчетен такой орган высшему менеджменту, и, вопреки заблуждениям, не осуществляет операций наказания невиновных и\или награждения непричастных.
Департамент по качеству собирает информацию о следованию установленным в компании правилам (иногда их называют Guidelines), запрашивает документацию по накопленным знаниям, проводит тренинги и презентации для менее квалифицированных сотрудников, подсказывает, направляет, отмечает эффективность.
Также этот отдел отвечает за сертификацию по международным стандартам, если того требует компания или клиент, или если в оной заинтересован сотрудник.
Эффективная работа этого структурного подразделения не только предлагает тривиальные решения или паттерны решений, но и существенно тренирует способности персонала эффективно разрешать даже внештатные и полу-внештатные ситуации на ходу.
В случае выявления нарушений создаются запросы на корректирующие и предупреждающие действия, в ходе которых анализируется и выявляется истинная причина fuck-up’ов, и их серьезность, согласно чему принимаются меры по их устранению, а также меры по их предотвращению.
Звучит громоздко, но на деле не добавляет особой бюрократии, не нагружает ненужной информацией рядовых сотрудников, и лечит многочисленные вялотекущие проектные заболевания а-ля «я забыл», «мне никто не сказал», «а какое моё дело», которые при других обстоятельствах решаются при помощи мануальной терапии и хирургии отдела человеческих ресурсов, вплоть до предупреждении о неполном трудовом соответствии, и даже увольнений.
Поэтому заявление компании «Мы довели до финала 500 старт-апов из 600», это действительно заманичиво. Вы дырявом решете они бы и половины не донесли…
Есть несколько условий, которые желательно также удовлетворить:
— Средний уровень зрелости сотрудников компании средний и выше;
— Компания имеет опыт разработки не-новаторских проектов, т.е. by the book;
— Такой отдел в принципе существует, а не зиждится на инициативе одного из директоров по развитию, который вполне уже может выходить на пенсию или мылить лыжи в компанию, где его принимают всерьез.
Обоснование этих пунктов могу предоставить по запросу.
Выделю две мысли из ответа:
а) Нужен отдел, который контролирует качество процессов и помогает их улучшать.
б) Заявление фирмы должно показывать качество (например 500 из 600 проектов).
Насчет отдела. Я пожалуй напишу статью, так как пришла в голову одна мысль.
По поводу заявления фирмы. В общем-то я согласен, что 500 из 600, гораздо лучше чем сказать просто 500. С другой стороны 5/6 (предположим, что это правда) могут быть получены абсолютно разными методами. И не всегда это значит качественные процессы и передачу знаний.
Я бы выделил контрапункты:
— Средний уровень зрелости сотрудников компании средний и выше;
— Компания имеет опыт разработки не-новаторских проектов, т.е. by the book;
— Такой отдел в принципе существует, а не зиждится на инициативе одного из директоров по развитию…
Если при их удовлетворении действительно сделано 500 из 600 проектов — это говорит о существовании качественных процессов и грамотной передаче знаний.
Такое по плечу даже молодым организациям, например веб-студиям: они вполне могут командой из 6-7 человек выдать на гора до тысячи проектов за десяток лет, предоставляя уровень качественного продукта в ~85% случаев.
С ними можно работать, и надеяться, что ситуация не намного ухудшится, если в течение года они не планируют расширяться более чем на 3 новых сотрудника (см. контрапункт 1).
По большему счету согласен со всеми пунктами.
Лишь небольшая ремарка. Вероятнее всего ситуация с 6-7 человек команда * 10 лет мне кажется маловероятной. Не скажу, что такого не бывает, но все таки за 10 лет, обычно состав меняется чуть ли не целиком.
Наличие такого отдела в наших украинских компаниях крайняя редкость. Особенно в молодых, которым по 5-10 лет отроду. В нашей конторе каким-то образом организовать QA процесс имели место на моей только памяти каждый год по разу и каждый год они проваливались по причинам, которые достоверно мне не известны, но о которых я могу судить, зная, как у нас все заваливается обычно: просто у директора на это нет времени, а инициатор (из руководителей отдела тестирования продукта), вдруг быстро понимает, что у него на это просто нет времени, т.к. у него куча и своих текущих проблем, а если он начнет распыляться еще и на эту новую серьезную задачу (учитывая отсутствия опыта и достаточных полномочий), то просто и со своими старыми задачами не справиться и с организацией QA процесса так же. В итоге инициатор, проведя ряд консультаций с начальством, подчиненными и знакомыми специалистами, понимает, что он не потянет и отказывается от идеи. По крайней мере именно так было в нашей конторе последние 5 лет и это происходит с завидной регулярностью.
А по поводу заявлений про 500 проектов, то я бы не особо верил заявлениям компаний. 🙂 ведь про проваленные 1000 проектов можно и умолчать. А те, кого вы со своими проектами заваленными обломали, вряд ли уже сильно смогут портить вам репутацию. Мир большой. Хотя конечно вероятность, что вы нарветесь на плохие рекомендации повышается с каждым проваленным проектом — это факт.
Гораздо больше значат заявления, что ваши разработчики участвовали в создании продукта, который успешно продается сотням тысяч пользователей (пусть даже в составе какого-то пакета или как бесплатное приложение к какому-то девайсу) и ваши заявления может подтвердить паблишер продукта. Тогда любой новый потенциальный клиент будет думать, что раз компания сделала это один раз, то она сильно попытается не ударить в грязь лицом и второй раз. А если там и основное руководство осталось прежним, то можно надеяться, что раз они смогли один раз собрать такую команду, то смогут и снова это сделать, даже если старой команды уже нет. Вобщем главная изюминка для потенциального клиента обычно не в количестве ваших успешных проектов, а в качестве. По крайней мере я бы, если бы искал производителя, то рассуждал бы именно так.
Да, действительно отделов таких особенно у молодых компаний нет.
Да и у больших он зачастую более формальный, чем реальный. Но об этом в следующей статье.
я своих обучаю по мере возможностей, только надо показывать преимущества такого подхода
>Соответственно, дай бог, если владелец и несколько менеджеров остаются и накопляют частичку опыта, а так ведь все выветривается.
Ну не совсем выветривается. Одни люди уходят, другие приходят. Один опыт выветривается, другой приветривается.
А насчёт ошибок это правильно. Когда я сказал, что ошибки не надо скрывать, а надо анализировать их причины, на меня посмотрели квадратными глазами. Есть причины скрывать. 😉
>Один опыт выветривается, другой приветривается.
Да, действительно, часть правды в этом есть.
Действительно новые люди приносят новый опыт в компанию.
Но тем опыт (даже скорее ошибки), который получен внутри компании крайне важен.
>А насчёт ошибок это правильно. Когда я сказал, что ошибки не надо скрывать, а надо >анализировать их причины, на меня посмотрели квадратными глазами. Есть причины скрывать. >;-)
Я тоже, что-то похожее говорил 🙂
Мне вот интересно, а как программисту писать документацию, если у него ,например, нету таланта написания документации, и само написание нормальной документации может занять у него на порядок больше времени, чем написание правильного читабельного кода (читаю сейчас Code Craft там столько полезных советов для улучшения качества кода, советую почитать ) с коментариями, которые уточняют этот код и делают картину еще яснее. А если вокруг горы документации, то как её эту документацию мэнеджить при каждом изменении кода? Мне кажется мало-вероятным заставить программистов писать досканальную документацию к коду, куда более мне импонируют идеи написания хорошо документированного кода (мысль, которая очень мне понравилась из книжки выше). Считаю также интересным решение предложенные в методологии CMMI(сейчас про неё нам рассказывают на лекциях в универе) — есть специальные люди, которые ходят и выбивают все информацию из программистов, ПМов, собирают разные документы сделаные во время проекта, вообщем документируют все и вся и складывают это все в репозиторий данных, и называется эта группа людей SEG (Software Engeneering Group).
Давай-те эту тему я вынесу в отдельный пост.
В общем-то программистская документация в этот пост не входила.
Кстати, вы не против если я вас поцитирую? 🙂 Просто, то что вы сказали — по большему счету очень четко подчеркивают проблему (почему документация не пишется).
Конечно, цитируете у меня возражений к этому не будет 🙂 (это даже польстит мне :)). Если вам интересно, то многие свои мысли я подчерпнул из книжки о которой уже упомянал — Code Craft (The practice of writing excelent code) и советую её для чтения каждому, кто хочет улучшить качество написания своего кода !
> есть специальные люди, которые ходят и выбивают все информацию из программистов, ПМов, >собирают разные документы сделаные во время проекта, вообщем документируют все и вся и >складывают это все в репозиторий данных
Я занимался полтора года похожими тасками на своей фирме. Правда не всю информацию я выбивал и не со всех, а только что касается сборки и сетапа продукта. И называли меня в то время Configuration manager.
Ну, информацию о сборке продукта проще выбить.
Слава богу, она примерно одинакова для большинства проектов.
Гораздо более важная архитектура проекта, какие-то необычные и сложные решения. А вот их очень сложно «вынять» из головы.
я отвечу на вопрос «как» — молча. или можно с шутками и прибаутками. мне, как мнеджеру, все-равно как именно программист будет писать документацию. то, что он должен ее писать — это безусловно. вопрос только в том, какую именно. документацию по API, по создаваемому коду, описание классов и методов — безусловно, кроме девелопера про это знает архитектор и больше никто. но время архитектора стоит очень дорого, чтобы он ковырялся в чужом коде. поэтому докуменацию к коду пишет автор кода. после того, как «отписки» подаваемые под видом документации будут забракованы и девелопер потратит часть личного времени, на написание адекватной документации, девелоперы начинают писать документацию сразу. а если в автоматической системе сборки стоит style checker, который «валит» билд с недокументированным кодом — девелоперы начинают писать документацию. и в данном случае не нужно обладать талантом написания документации.
SEG занимается не документированием кода, а сбором, систематизацией и сохранением знаний. и этим конечно не занимаются девелоперы.
Молча это конечно вариант :). Лично мое мнение, что документация должна быть, но её должно быть совсем не много, а главное, что следует старатся делать это добиватся от разработчика написание чистого, понятного кода с качественными (но не количественными комментариями ) комментариями в нужных местах, с именами переменных, которые могут обьяснить многое своими именами… Писать хороший и понятный код это уже весьма тяжелая работа, так еще нужно свалить на разработчиков написания томов документации (например в большом проекте), думаю это не слишком благоприятно скажется на качестве созданного продукта.
Для больших проектов, чистый код — это не решение.
Я например завтра могу скачать код ядра Linux’а. Код там чистый
Но вот без документации, я пол года наверное буду разгребаться.
Одна из самых важных документаций
а) Как собрать продукт
б) Какие есть модули, за что отвечают и где храняться
в) Архитектура проекта (как что с чем взаимодействует)
г) Документация сложных мест
добится от разработчика чистого и понятного кода довольно просто. на то есть метрики и код-чекеры. я уже говорил, после того как самый упрямый разработчик, которому очень нравятся табуляции в 8 пробелов и названия переменных mfvrb или mbrd, перепишет код после того, как завалил билд. а потом еще поработает сверхурочно бесплатно, потому что в то время когда он переписывал свой код, он должен был делать другие таски. вот даже самые упрямые сдаются.
комментарии в коде есть неотъемлимая часть кода. они лепяться не где-попало и отображают действительно важную информацию, которую по-другому отобразить нельзя.
а код (including comments) — это работа девелоперов, да она не простая и не легкая. так девелоперы и получают на порядок больше, чем бибиотекари и в разы больше чем мастер-токарь на заводе, а это тоже довольно сложная профессия. и уровень оплаты, и позиция в той или иной конторе, зависит от того, насколько качественный код, насколько понятный код и как быстро создает девелопер. это если чисто технически, политически ситуации бывают разные, но на то и конкуренция, чтобы достоинства не терять.
со статьей согласен полностью. проблема хранения и передачи знаний стоит в IT очень остро. не многие владельцы и топ-менеджеры понимают, что у них просто нет более ценного капитала, чем знания их сотрудников. тут уже говорили про SEG, но в украинских реалиях CMMI-3 на харьковском рынке имел только Miratex. сейчас наверное имеет еще и GlobalLogic. в остальных конторах выделенный SEG невозможен, из финансовых и ресурсных соображений. хорошей практикой для накопления знаний является наличие корпоративной Wiki. которая оперативно обновляется в соотвествии с деятельностью проектных групп. и вот уже накопленные знания можно модерировать, редактировать, систематизировать и т.д. я как-раз сейчас занимаю внедрением подобных практик у себя в отделе, проблема только одна — нужно побудить, мотивировать, умолить, заставить или как-то еще организовать людей, чтобы они туда писали. как, я еще не придумал. но это уже моя проблема 🙂
Именно-именно. И это не только украинская проблема.
С разработчиками проще. У них хоть знания не киснут. Я имею в виду, что какая-то библиотека или кусок кода или документации остается актуальной и легко записываема в Wiki.
Гораздо сложнее все обстоит с бизнес процессами в фирме. Они гораздо хуже формализуются (особенно таким образом, чтобы сохранился их дух, а не буква).
и тут согласен. хотя в любом случае можно, а значит и дОлжно, знания накапливать. я пришел к этому сам, когда мне понадобилось сделать одну вещь, которую я успешно реализовал за 6 месяцев до того. и реализация была довольно замороченной — шутка ли три ворэраунда вокруг портального JSR-168 движка. и я с ужасом понял, что мне придется восстанавливать свои знания почти с нуля. подумав еще я понял, что я не одинок 🙂
[…] Виктор Ронин. Ужас-ужас и полная корпоративная амнезия. “[.. меня коробит, когда] компания успешно […]
Предположим, так и происходит. Люди накапливают свой опыт. Эти люди называются компания, фирма. Опыт накопленный лежит в удобном, компактном виде. Лежит внутри компании. Записан он так, чтобы быть полезным любому пришедшему сотруднику, то есть любому специалисту. То есть специалисту не пришедшему он будет полезен в той же степени. Является ли этот опыт капиталом, ресурсом, который даёт преимущество компании, и которое она потеряет с его публикацией?
Может быть, руководству не просто некогда, но и не хочется вести такой «личный дневник компании» со всеми интимными подробностями, слабыми сторонами?
а действительно, каков максимальный размер комметария? выкладываю по частям, если появится оригинальный, части можно убить.
—————————————————————————————————————
know-how? и да, и нет. да — потому что срез знаний уникален, касается технологических особенностей разработки проектов, и (главное с точки зрения бизнеса) накоплен за деньги компании. нет — по первым двум причинам. попробую пояснить:
Насчет размера — увы не знаю.
1) уникальность опыта. все дело в том, что в подавляющем большинстве случаев программирование — это торговля воздухом. т.е. программисты создают некий уникальный продукт на машинах, изобретенных и собранных одними людьми; с помощью языков, изобретенных и написанных другими людьми; используя framework’s изобретенные и написанные третьими людьми. все компоненты в отдельности доступны любому человеку, который может воспроизвести этот самый уникальный продукт самостоятельно. часто технлогии, используемые при разработке продукта являются open-source. т.е. не стоят ровным счетом ничего. опыт позволяет ускорить разработку. более того, опыт, в том числе и систематизированный, никогда не является пошаговой инструкцией к воспроизводству некоего продукта. это всего-лишь описание наиболее сложных, трудоемких и технологически сложных нюансов. плюс архитектурная документация — того или иного уровня абстракции. плюс документация по использованию API. возможно, кому-то этого будет достаточно, моя практика показывает, что без консультаций команды, без адаптационно-интеграционного периода вся эта информация если не бесполезна, то скорее порождает дополнительные вопросы, чем дает ясные ответы.
2) технологические особенности проекта. огромная часть продукта относиться к вещам «самоочевидным» и «не военным». иногда это не так, чаще всего — таки и есть, но объем именно такого кода исчисляется сотнями человекочасов, чтобы только его физически написать, не говоря уже об отладке и тестировании. таким образом, невозможно передать проект третьей стороне без инвестиций на исследование существующего. с точки зрения бизнеса это крайне не выгодная мера, к которой прибегают в самом крайнем случае. здесь также следует отметить, что огромная часть этого «самоочевидного» кода следует из знания фрейморков и компонентов, на базе которых создается проект. без этих знаний, даже с подробнейшей документацией, невозможно проект даже поодерживать, не говоря уже о развивать. с точки зрения бизнеса — плюс инвестиции на изучение технологий. и не следует забывать об особенностях применения этих технология, не все работает out-of-the-box. я скажу больше, очень многое не работает out-of-the-box. тут поможет документация, но только если досконально знать what-exatly-is-in-the-box.
и последнее, я говорю в первую очередь про аутсорсинг проекты и подразумеваю, что техническая документация не содержит коммерческой информации. в случае с продуктовыми решениями, наверняка есть ограничения на ту или иную функциоанльность, которая безусловно является know-how. но об этом пусть расскажут представители продуктовых компаний. в остальном, ситуация с пактетом документации представляется мне независимой от деятельности компании и общей для всех. равно, как я считаю документирования благом, а опасения отностительно раскрытия информации не обоснованными. возможно я не прав, тогда жду аргументов против 🙂
Кстати, интересно, что все нырнули в облась — код/ноу-хау/документация.
Изначально я статью писал скорее о бизнес процессах.
Черт с ним с технологиям, как-то , хоть и не слишком быстро, но программисты ими деляться.
А вот бизнес процессы, почему-то совсем плохо люди друг другу передают.
потому, что как нет двух одинаковых людей, так нет двух одинаковых сообществ. а следовательно нет двух одинаковых контор. это во-первых и в-главных. а во-вторых, инвестор (или заказчик, или оба) заинтересованы в получении прибыли. им приходится доказывать, что постановка бизнесс-процессов не расходует их средства, а наоборот — экономит. доказывать, зачастую, долго и нудно. повторяя одно и тоже. с другой стороны можно просто работать, просто получать зарплату, а потом просто уйти. и большинство выбирает… вот и получается так, что бизнесс-процессы не шарятся — им не учатся, и их не настраивают. потому что лень, или потому что «это невозможно», говорят люди, которые каждый день делают невозможные вещи 🙂
В общем-то согласен.
Просто меня удивляет, что технические знания в общем-то лучше шаряться, хотя к ним относятся теже самые аргументы.
Единственное, что приходит в голову, что технические знания легче формализуются и меньше денег уходит на проверку.
э-ма, от чего же, отнюдь не единственное? любой framework, workaround, tips&tricks ценен сам по себе, независимо от бизнесс-целей и поставленных задач, только от области применения. например, вот код CSS, который позволяет подсветить checkbox в IE, Opera и FF:
input[type='checkbox'].highlighted {outline: 2px solid #F00}
кому будет полезно это знание? всем, кому нужно подстветить checkbox в трех браузерах. а это и программисты, и веб-дизайнеры, и верстальщики, и даже блоггеры.
область применения скажем в чистом виде ХР менее очевидна. ХР хорошо подходит мелким подрядчикам и стартапам, но не все могут себе позволить роскошь парного программирования. или во многих случаях бессмысленна практика stand-up митингов.
целевая аудитория меньше. знаний о бизнесс-ценлях, о стратегических задачах компании, о тактических проблемах компании необходимо больше, чтобы понимать, насколько описанный процесс подходит компании. а если не подходит, то как его эффективно модифицировать. а это тоже навык и квалификация, и нужно просчитать риски, прибыль которую внедрение даст, убытки которые с собой принесет… не всякий программист это может, а чаще всего программист создает value, код и функционал. и не умеет делать менеджерскую работу, а менеджер уровня top-middle стоит дорого, и функционал создавать, в том же объеме, что и программист, не может. а платить ему надо. вот еще несколько причин.
Да. Пожалуй.
Одна вещь, которую еще хотел сказать.
Имеет спирать только то, что можно использовать и получить прибыль.
И в этом смысле есть куча вещей, которые сами по себе имеют малую цену
код/документация/заказчики/идея/контакты очень взаимосвязанны.
Кража одной вещи, редко даст возможность получить прибыль.
>Является ли этот опыт капиталом
Как может информация быть капиталом, если она не может быть собственностью? Информация остаётся в головах людей, они её разнесут по миру. А изложенную в удобном и компактном виде разнесут ещё быстрее. 😉
Я не согласен с этим.
Код написанный программистом — является капиталом, так как его можно продать (если он юридически принадлежит компании).
При этом код — очень легко переносится по миру (даже лучше чем мысли в головах).
>1. Код написанный программистом — является капиталом, так как его можно продать (если он юридически принадлежит компании).
>2. При этом код — очень легко переносится по миру (даже лучше чем мысли в головах).
Я думаю, это разные исходные коды. Продать можно проприетарный исходный код. Но можно ли сказать, что он легко носится по миру?
Но вообще-то я говорил не про исходники, а про *опыт*, про что написано в комментарии, на который я отвечал. А исходники да, можно назвать капиталом.
Исходник всё-таки отдельнее от программиста, так что программист может даже не узнать собственный исходный код. 😉 Исходный код загружается в компьютер, это его предназначение. Опыт загружается не в компьютер, а в голову человека, нельзя пользоваться опытом, не нося его с собой. 🙂
Собственно об этом речь в статье и шла, чтобы часть опыта, которую можно выгрузить из головы в компьютер — таки выгружать.
В тот момент, когда опыт выгружен из головы то он не многим отличается от программного кода (в смысле, что он имеет ценность).
Говорили мы про капитал. Например, ни солнечный свет, ни помидоры капиталом не считаются, хотя имеют ценность.
М… Возможно, я выразился не самым точным методом. Однако:
http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BF%D0%B8%D1%82%D0%B0%D0%BB
«Капитал — это совокупность отношений и предметов, выраженных в виде стоимости, способной приносить прибавочную стоимость или убыток.»
Там дальше описано ситуация с станком. Она именно такая, как и с описанием знаний. Сами по себе они не имеют смысла, но если приложыть к ним работника, то они как раз являются методов получения прибавочной стоимости (либо убытка 🙂
код, написанный программистом, не является капиталом, потому что не стоит ровным счетом ничего. собственностью компании является функционал и логика, которую код реализует. бизнесс-цели очень просты — автоматизация и унификация повторяющихся процессов; сбор и представление статистики; сбор, хранение и представление данных; моделирование процессов и т.п. эти задачи решает не код, но функциональность. иными словами, я могу продать исполняемый бинарник, но я не могу продать код сам-по-себе. код не является капиталом.
Спорно.
Чуть выше давал эту ссылку:
http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BF%D0%B8%D1%82%D0%B0%D0%BB
“Капитал — это совокупность отношений и предметов, выраженных в виде стоимости, способной приносить прибавочную стоимость или убыток.”
С чем я согласен, что функциональность это основная ценность кода. Но сказать, что код не является капиталом, мне кажется неверно.
Прибавочная стоимость в данном случае не имеет значения. Капитал — один из производственных ресурсов. Экономическая теория занимается ограниченными ресурсами. Это если мы переключимся с марксистской политэкономии на современную западную экономическую теорию.
Ограниченный ресурс такой, что, если ограниченный ресурс потрачен на производство одного блага, он не может быть потрачен на производство другого блага. Опыт не является ограниченным в этом смысле. Так же, как и любая информация.
Вот об этом я говорю. Нельзя сказать, что всё, что имеет ценность, есть капитал. Я уже приводил примеры вещей, которые имеют ценность, но не капитал.
Те же рассуждения можно провести не только для капитала, но и для другой собственности.
Кстати, советую читать английский вариант статьи о капитале, там более широкие взгляды. 😉
Буду читать английский вариант 🙂
Думаю на этом перестаю спорить, так как спор в сторону ушел дико.
Опыт нельзя настолько хорошо описать, чтобы вот любой входящий в двери мог им сразу воспользоваться.
Естественно к этому надо стремиться.
А насчет личного дневника и интимных подробностей. Код — сто процентов является капиталом и ресурсом. И если его опубликуют то компания зачастую может вылететь в трубу.
С таким же успехом, если компания откроет двери и напишет объявление, в среду вечером никого не будет — заходите и выносите всю мебель и сервера и вам за это ничего не будет.
Так, что вопрос охраны своих капиталов от кражы лежит в перпендикулярной плоскости относительно вопроса накопления капиталов.
не согласен. описанный случай справедлив только в том случае, если опубликуют весь код или какую-то законченную логику. если я опубликую (да что там, каюсь, присылал примеры кода несколько раз) отдельные классы или куски кода — это «белый шум», совершенно бесполезная информация. опять-таки, код без используемых библиотек, без сборочных скриптов, без «обвязки» из пропети-файлов, мета-информации, дескрипоторов, также никому не нужен.
Я в основном хотел сказать, что код является капиталом.
Я согласен, что часть кода вероятнее всего может иметь нулевую стоимость.
Зачастую код без документации даже может иметь близкую к нулю стоимость.
Но вот, когда несколько вещей собираются воедино, они вполне таки могут стоять много.
в том-то и дело, что когда несколько вещей собираются вместе — это уже не просто код. хотя возможно, мы понимаем под кодом разные вещи — я имею ввиду просто набор искходников, без документации, без скриптов сборки, без используемых библиотек, без файлов-ресурсов.
Я думаю мы понимает код одинаково.
Просто набор исходников, тоже может быть полезен/используемым.
Безусловно ценность его гораздо меньше.
В ответах обсуждение ушло в сторону. Всё-таки статья не про код, хотя это тоже интересная тема. Ушло, может, потому что нам в голову приходят мысли о сущем 🙂 о том, что маячит в реальной работе (горы тех. документации). А то, о чём речь в статье, как я её понял, в жизни не встречается совсем — обсуждаемая проблема-то именно в том, что никто не пишет документации «менеджерской», опыт решения проблем остаётся в голове. Поучительные (в хор. смысле) истории можно совершенно случайно «в курилке», а — вероятнее — можно и не услышать. И тратить время, барахтаясь в решённых когда-то проблемах, вынужденно откладывая оставшиеся. Похоже, что компания должна систематизировать повседневные решения (ну, не каждый пук, разумеется) в формате курсов, например, и регулярно сотрудников подтягивать до этого уровня внутренним обучением.
Наверное, такую модель с курсами уже давно применяют 🙂 Может, одна-две мегакорпорации.
Записать опыт (в полезном виде) мало кто сможет — сформулировать трудно. Этим займётся отдельная группа писателей, как это делают технические писатели.
Это такой научно-исследовательский институт получается. Кому он нужен?
Почему все любят возводить все сразу в полный абсурд (научно-исследовательский институт).
Ведь, например запись каких-то крупных лаж и курсы звучит нормально.
Я не хотел возводить в абсурд 🙂 Вот «Департамент по качеству», который обсуждался выше, и есть этот НИИ, мне кажется. Он исследует, свои изыскания преобразует в «труды», которые ещё должны быть понятны слушателю (читателю?), а не вылетать в другое ухо с зевком. Здесь я теряюсь в чаще пессимизма 🙂 Надеюсь на Вашу статью по этому вопросу («насчёт отдела», Ваши комментарии выше).
(Анонимно писать пока проще, интересно обсудить мысль, имя не прячу 🙂 Пока я в этой теме один аноним)
ok. Вероятнее всего это у меня негативная реакция на слово НИИ.
Статью напишу по этому поводу, но вероятнее всего через пару дней.
Жаль, что писалось анонимно. Но, аноним точно подчеркнул, то что я хотел сказать.
Что информация о фирме — хороших и плохих бизнес решениях и бизнес процессах должна передаваться не в курилке. А новые люди, должны иметь возможность распечатать 20 страниц, прочесть их в первый день и знать на что уже наступалось.
Думается, что такое обучение касается исключительно внутренних «изобретений», оно не должно компенсировать недостаток квалификации сотрудника, его проф. подготовки, основывающейся на общедоступных источниках.
И, возвращаясь, к «отъемлемости» записанного опыта — исключительные права на материалы этих курсов должны быть у компании, видимо.
Безусловно.
Подобный велосипед давно есть, и называется Knowledge Management.
Лучше всего поставлено в западных компаниях, т.к. изобретено там. Видел у западного заказчика метры распечаток с проектами конца 80-х!
Возможно, было в СССР, но мне в силу возраста в советских конторах с методологией поработать не удалось.
Работал в IBS — сбор инфы с проектов там работает. Ни один проект бесследно не проходит. Другое дело, интересующихся этими артефактами — мало, т.к. само по себе дело трудоемкое — разгребать эти множественные «meeting minutes» и техзадания, и второе — в артефактах далеко не все. Попробуйте организовать, чтобы РП или специалисты честно записывали в постмортем проекта свои косяки :)))
Я — записывал, себе интересно потом. Других таких записей не встречал.
Я уже писал, что хочу написать пост по этому поводу. Может завтра засяду.
Собственно это и была моя ключевая идея, которую я хотел высказать
а) Люди просто не любят записывать информацию, которая лично им уже не понадобиться.
б) Люди еще больше не любят записывать информацию, которая их может дискредитировать
Так, что зачастую (не всегда) получаются что все эти отделы качества и knowledge management толкут воду в ступе.
Хотел как раз написать 🙂
И немного добавлю. В хороших с точки зрения сотрудника-программиста компаниях его накопленные знания (и скорее всего нескольких его коллег) помогают не просто собрать, а еще отредактировать, оформить, и опубликовать. И называются такие знания… внимание!… книги! 🙂 и альманахи 🙂 Все мы знаем где купить книги, например, по С++ (на Петровке, на Амазоне, etc.), и даже нескольких авторов помним. А компании, которые помогли создать эти книги знаем? Далеко ходить не нужно — тот же Амазон. Еще Microsoft, Borland, IBM… Еще… не приходит на ум 🙂 Но их много 🙂 Вот у них и нужно учиться такому виду деятельности, как Knowledge Management 🙂
Хорошо с C++. Ему уже под 30 лет и есть сотни тысяч людей, которые им занимались.
Так что найти толковую книгу не проблема.
А, что делать с решением проблем с заказчиками, которые живут на другом континенте и которых никогда не видел. Как поступать, как проект выбивается из бюджета.
Хотя есть много книг на похожие темы, но они зачастую достаточно общие.
Опыт же в компании в этом смысле просто золото.
Единственное, что могу сказать — помощь нужна скорее в сборе и систематизация.
Редактирование, оформление и публикация для такого типа знаний будет лишь накладным расходом. Может если фирма состоит из тысчи человек — это позволительный расход.
В фирме из десяти человек, это чистый расход.
еще раз, знания очень специфичны. оформление их в виде книги не имеет смысла. оно не рентабельно и не принесет никакой выгоды. а выпускать книги в виде социалки и рекламы… конечно можно, но пока есть масса других способов мотивации и других неудовлетворенных потребностей сотрудников.
Вы не поняли мессадж 🙁
Когда-то С++ был новинкой, но книги (статьи и т.п.) сделали его общим, а не специфическим знанием. Согласен, пример не сильно удачный. Пусть это будет не С++, а GSM, или IM (Jabber, ICQ). По ним тоже есть популярные книги. Но популярными они стали не сразу. Вначале были внитренние знания отдельных компаний. И первые версии продуктов (зачастую, прототипы), построенных на этих знаниях. Через несколько лет (месяцев?) появились внутренние сборники знаний — книги. В Макдональдс и сейчас книга по организации бизнеса — внутренняя. Потом внутренние книги издали в мир. По разным причинам.
Мессадж был о том, что не нужно выдумывать велосипед, и создавать какую-то супер-пупер систему накопления знаний компании. Нужно создавать книгу (или книги), и оформлять эти знания изначально в полноценный продукт (я не программном, а о книге как продукте).
Самый яркий для меня пример — Microsoft. Издает книги по каждой своей технологии, и сразу для разных уровней читателя и разных целей. И даже больше — организовали НЕСКОЛЬКО своих издательств (Microsoft Press, Patterns & Practices, MSDN Magazine, …). Вот вам пример на блюдечке 🙂
Я бы сказал, что есть знания абсолютные и есть знание относительные.
Абсолютное знание например 2+2=4. В десятичном счисление и математику, которую изучают все — это правда в любой точке земли в любое время суток, при любой погоде.
Аналогично описание языка C++, протокола ICQ и описание действий в McDonalds.
Большинство вещей которые делается в IT являются знаниями относительными. Например, я не верю, что кто-то сможет описать схему как премировать сотрудников, такую, чтобы она работала на любой нации, в любой фирме и т.п. Эти знания, очень зависят от гигантского количества факторов.
Именно поэтому я выступаю за сбор и анализ таких знаний внутри фирмы, а не просто попытку переноса знаний из одной фирмы в другую (при том, что фирмы могут находится абсолютно в разных ситуациях).
Бляха муха… 🙂
«Описание языка C++, протокола ICQ делаются в IT и являются знаниями относительными. »
Согласны с утверждением? Не делите на черное и белое. Учитесь «настраивать» инструмент, а не только его «использовать». Ведь чем мастер отличается от ученика? Именно умением настроить а иногда и построить инструмент. Так в музыке, так в архитектуре, так в точных науках… Так почему же не в IT?
«Бляха…» относилась к схеме премирования . Книг на эту тему — кучища. И в лучших из них описаны не только схемы для разных случаев (исследование, раздаботка, тестирование — пусть и не в области IT, а в других произодсствах), но и методики внедрения этих схем.
«…муха» — где я выступал ПРОТИВ сбора знаний внутри фирмы? Опять мессадж не дошел? Я предложил именно ВНУТРИ фирмы накопить знания в виде книги (книг). Так, как это делают другие. Не брать ИХ книги, а взять их ПОДХОД…
Уффф.
Я вполне понял вашу идею
а) Сбор информации
б) Издание в виде книг
Насчет а) — мы оба сходимся во мнении.
Насчет б) у нас мнения разные. Я считаю подготовка и издание в бумажном виде просто трата времени и денег.
Мой пример о неприменимости знаний я привел со стороны третьей фирмы. Знания изданные в виде книги в фирмой будут вероятнее всего бесполезны остальным фирмам. (соответственно, книгу никто не купит).
для того, чтобы создавать книги, кто-то должен заниматься сведением знаний в читабельный вид. вопрос — кто будет это делать? держать специальных людей — как это наверняка делают в Microsoft — могут себе позволить очень не многие. это первое.
второе — последнюю книгу по программированию я купил в 1997 году. большинство книг устаревают раньше, чем успевают выйти из типографии. даже по технологиям Microsoft. это полезно людям, которым необходимо понять принципы технологии, но бесполезно — людям, которые уже «в теме».
третье — я полностью согласен с Виктором, есть фундаментальные знания, а есть знания прикладные. книга как продукт направлена на то, чтобы быть продаваемой. я не верю, что еще одна книга о том, как правильно программировать с использованием Struts окупит затраты на подготовку и тираж.
и последнее — в систему накопления знаний пишут носители этих самых знаний. книги пишут люди, которые умеют это делать. это искажает информацию. система накопления знаний доступна онлайн, в ней есть поиск, фильтры, возможности атачить файлы с примерами. книга — либо пачка бумаги, либо электронный файл. это не удобно. не нужно думать, что создатели Вики, Кофлюенса или Википедии поголовно дураки. назначение книги и системы накопления знаний кардинально различны. и не нужно путать кислое с квадратным.
Вы считаете, что электронные издания издают не книги? Не ТОЛЬКО книги (как и печатные, впрочем), но и книги тоже. Для вас сильно отличается электронная справка по VS 2008 Team Suite от печатной книги по этому же инструменту? Для меня — практически не отличаются. Может из-за того, что после 1997 года Вы перестали заниматься собственным образованием, и «схватываете на лету» (а я бы это назвал — скачете по верхам)? 🙂
Но ведь не все закончили учиться вместе с Вами 🙂 А многие наоборот — только начинают. И именно на них направлена «некая система внутренних знаний компании», которую мы здесь обсуждаем 🙂 На Вас она точно не направлена — даже при ее существовании Вы бы ознакомились только с «изданием» 1997 года 🙂
Ну о формате мне даже отвечать лень. 🙂 Не умеете (или не желаете) обрабатывать информацию разных форматов — ваша проблема 🙂 У многих такой проблемы нет.
м-м-м, мне почему-то не совсем нравиться Ваш переход на личности. не знаете, почему? вероятно Вы, как человек безусловно ителлигентный и воспитанный, признаете, что были не совсем правы на мой счет, нес-па? Вы меня не знаете, я Вас тоже, но я не рассуждаю на тему того где Вы «скачете» и когда «перестали учиться».
собственно кроме навешивания ярлыков на мою скромную персону Вы так и не ответили по существу. попробуйте еще раз, чтобы нам было о чем поговорить.
Не принимайте близко к сердцу, и подсчитайте количество смайликов 🙂
Я бы сказал, что электронная справка/Wiki — это не книга.
Есть несколько ключевых отличий
а) Книгу невозможно изменить после издания.
Точнее можно, но на это уходит очень много финансов. Исправление, переиздание, распространение.
б) Даже при переиздании, невозможно «изъять» старые версии книги.
в) Книгу не могут редактировать 3rd party (то, что возможно в wiki)
г) Книга очень слабо поддерживает гиперссылки. (можно писать, читай на странице 27). Но, если книга будет напичкана такими переходами, то тогда ее невозможно будет читать.
Итого, не любой текст — это книга.
Мне кажется Ракицкий имел ввиду, что просто к накоплению знаний необходим системный подход, который позволит пользоваться знаниями не на определенном участке проекта в определенный участок времени, а когда знания станут полезны и применимы ко многим ситуациям. Т.е. недостаточно просто взять и описать исходные и выходные данные и описать примененную методику при решении проблемы, как это сделали бы в Вики, так как это если кто-то и прочитает потом, то махнет на это рукой и скажет «А, у меня совсем другая ситуация», и даже не факт, что станет дочитывать до конца. Ракицкий, по моему, имел ввиду, что при документировании знаний нужен обязательный анализ и четкая каталогизация. Чтобы читатель четко знал, где и в каком разделе ему искать полезную информацию (и чтобы на поиск у него уходило минимум времени). В этом и состоит искусство написания справочника.
Вот, что писал Артур Ракицкий:
Я согласен со всем, кроме слова опубликовать.
Фактически это слово сейчас применяется только для печати книг. Возможно я слово понят неправильно.
Публикация внутренних знаний фирмы, мне кажется экономически невыгодно. Расходов много, а дохода от этого будет мало.
Ну публикация вообще вещь сугубо отдельная от темы разговора. Я думаю с этим словом он просто погорячился. Хотя когда материал уже готов, то почему бы и не опубликовать, если это даст прибыль.
Книга может быть в PDF или HTML формате.
Опубликовать можно и на сайте компании.
Публикация (on-line) от простого «выкладывания» файла отличается процедурой регистрации издания и сопутствующим распространением новости о выходе издания для широкой аудитории (или в рамках фокус-группы).
А продавать можно на Amazon-е.
Значит я слово опубликовать понял неправильно.
Тем не менее, я не слишком положительно отношусь к идеи публикации накопленных бизнес знаний.
С одной стороны, это не слишком хорошо, так как может затрагивать вещи, которые лучше из фирмы специально не выносить.
С другой стороны, накопленные знания (именно бизнес знания, а не технические) тяжело применимы в других фирмах.
Вы отлично поняли часть моего мнения! 🙂 И растолковали, за что отдельное спасибо! 🙂
Вторая часть заключается как раз в том, что формат книги (способ подачи материала, оформление) отличается от свалки документов еще и наличием «основной линии», лейтмотива, благодаря которому кнугу легче воспринимать целиком, но постепенно — от 0 до 100%, глава за главой.
У свалки документов с самым изощренным поиском этого качества нет.
Вики (и некоторые форумы) — нечто среднее между книгой и свалкой. И само по себе хранилище в формате вики ОЧЕНЬ сильно зависит от аудитории, среди которой корректоров, редакторов, а тем более писателей — мизерный процент :(.
Ну, я бы сказал, что формат хранения знаний (книга, wiki, форум, мусорный ящика) хоть и касается изначальной темы, но достаточно автономен.
[…] написал статью о том, что в компаниях знаниях не накапливаются, а […]