Как это часто бывает – подобное притягивает подобное. Так было тогда, когда надо было подготовить материалы по развитию «цифровых» компетенций на предприятиях ТЭК, так получилось и в этот раз. Началось все с того, что мой рассказ о сообществах в рамках первой конференции по управлению знаниями в ИТ, мы решили привязать к «чаяниям» (задачам/проблемам), стоящим перед СТО (Chief Technology Officer). Не в ИТ-компании в целом, - по моему глубокому убеждению там, как и в любой другой компании, важно помнить о реализованных хорошо и не очень проектах, знать продукты других подразделений или направлений бизнеса, уметь работать с клиентами, что не отличается от остального мира, - а именно в блоке разработки.
Как водится, первые мои вопросы «посмотреть за задачу глазами СТО» были отправлены друзьям, которые собаку съели на разработке. Вопрос звучал примерно в такой формулировке: «При разработке/тестировании какие постоянные типы проблем (внезапных задач) возникают с точки зрения тех, кто отвечает за весь процесс?» Анна Кравец, ANROM, Киев, Родион Нагорнов, Лаборатория Касперского, Москва, и Евгений Додо Пицца, Москва, - те герои, которые помогли.
Если обобщить ответы трех человек, то получилось следующее. То, как было написано – оставил почти без изменений, чтобы авторам было понятно, кто писал:
1. Планирование работ/оценка сроков/постановка задачи:
1.1. Фактические затраты времени превышают плановые (огромная проблема оценки сроков)
1.2. Трудности перевода между языком бизнеса и техническим языком, необходимость в общении через PMов, которые могут быть испорченными телефонами
1.3. Можно подумать в сторону переиспользования опыта реализации проектов разными проектными командами, чтобы точнее прогнозировать сроки на релиз, затраты, хедкаунт и т.д. на новые проекты
1.4. Нет понимания кто чем занимается сейчас или будет заниматься. Возникают конфликты и дублирующие решения.
2. Развитие процессов разработки, создание новых продуктов:
2.1. Киллер-абилка профсообществ для СТО). СТО же у нас должен смотреть вперед и вверх, предугадывать, каким дальше будет рынок, куда развивать продукты, какие новые потребности появятся, какие старые отомрут и т.д. А знания у нас порождают новые знания. И опыт членов профсообщества, например, разработчиков на С может породить новые идеи. Если в профсообщество грамотно вбросить проблематику, над которой им надо порассуждать (например, друзья, Россия собралась открывать базу на Луне. Что из софта им там может понадобиться такого, чего на Земле нет и не нужно?) Опыт, скилы, фантазия и коворкинг могут СТО дать очень даже четкие и профитные векторы для развития
2.2. Рабочая группа, которой позволяют пофантазировать на заданную тему. А дальше уже СТО может отдать другой группе, например, экономистов, несколько векторов, чтобы они предположили, как оно выйдет, в деньгах
2.3. Теряется контроль над техническими решениями. Могут получаться плохие решение. Частично решается архитектурными воркшопами.
2.4. Нет четкого понимания куда расти, что изучать, на какие части системы смотреть внимательнее.
3. Ускоренная адаптация новичков:
3.1. Сложно онбордить новичков. Надо многое рассказать про систему, прежде чем новичок будет способен перформить самостоятельно. Задача частично решена документацией.
4. Повторение – мать учения или перестаем изобретать велосипед:
4.1. Разработчики наступают на одни и те же грабли (не делятся между собой информацией о находках и обходных путях, либо не воспринимают информацию, когда кто-то ей делится)
4.2. Люди могут не знать, что подобную проблему уже решали. И решить новым способом. И это будет уже четвертый вариант решения проблемы.
4.3. Опыт маркетингового позиционирования похожих старых решений или (если есть) решений конкурентов при планировании новых фич и рассмотрении идей для включения в итоговый скоуп (какая фича может взлететь и порвать рынок, а какая будет полезна только в воспалённом уме предложившего, даже если выглядит она красиво).
5. «Мои знания – моя сила» (и только моя):
5.1. Bus factor=1. Есть спец, который вместо шаринга знаний всё больше и больше срастается с каким-либо компонентом. Ему быстрее сделать самому, чем объяснять другим. Не самый плохой вариант, хуже когда это явная политика safety job.
5.2. Люди не общаются, низкий уровень передачи информации и опыления.
5.3. Люди сознательно не сообщают об успешных решениях, так как чувствуют угрозу или конкуренцию со стороны коллег.
Следующее направление развитию творческой мысли задача Марина Корсакова, МИРБИС, задавшая вопрос о специфике управления знаниями в IT. Наиболее интересные комментарии также привожу здесь. Тут, к слову, мнения разделились: от того, что при разработке своей специфики нет, до того, что отличается, и очень сильно. Решайте сами.
1. Высокая скорость обновления знаний:
1.1. Объем знаний, скорость их накапливания больше. Программист написал скрипт, для этого разобрался в чем-то, после этого все, скрипт работает. Год работает, два работает - а потом не работает. И нужно откуда-то доставать знания, как он был написан два года назад, и почему. И так - каждый день. И поэтому - это боль.
1.2. Судя по комментариям, это обсуждение «ушло» в сторону того, что вне зависимости от размера команды надо прививать людям азы документирования, которые будут позволять быстро понимать существующие решения.
1.3. И еще одна ветка комментариев, которые я бы свел к «Быстрее. Адреснее. Полезнее». Суть в том, что скорость принятия решений в разработке выше, рекомендации должны быть не «в целом по больнице», а адресные, под задачи конкретного человека. Полезнее – притянул за уши, но звучало, что качество разработки «всплывет» гораздо позднее. Скорость – это звучало во многих комментариях, т.к. в ИТ – «Проблема-Обоснование-Решение», постоянный R&D с чуть ли не еженедельной сменой технологий.
1.4. «В ИТ знания устаревают очень быстро. Если есть какой-то курс, то через год уже устаревший, через 2 года уже не актуальный. Квалификация, например, в декрете теряется так же быстро, если в декрете человек не обучался, то он может выйти на 2-3 позиции ниже, чем был до этого».
2. Отдельно вынесу пост про то, что при каскаде – все очень похоже, при Agile – появляется сложность реализации:
2.1. Проблема «что документировать» и с «какой детализацией», чтобы, грубо говоря, не противоречило Agile-у
2.2. Минимум стандартов кодирования, т.е. каждая реализация «похожего» - разная. И это не всегда плохо.
2.3. Множество используемых технологий. Одна и та же задача, реализуемая на разных технологиях или даже версиях технологий, может реализовываться очень по-разному. И это не то же самое, что открыть магазин по описанным стандартам, но в другом городе.
2.4. Множество «черных ящиков» (знаю, что произойдет, но не знаю как это делается и какие подводные камни), которые нужно использовать в работе, написанные такими-же agile-командами, только внешними.
2.5. Быстрое устаревание.
2.6. Т.е. с одной стороны управление знаниями внедрить сложней, с другой крайне важно, т.к. скрытая ошибка растиражируется мгновенно на миллионах пользователей. И длительного тестирования позволить себе не могут.
3. Мнение «изнутри» о том, что не отличается ничем:
3.1. Есть люди, у которых формализация и оцифровка знаний - должностная обязанность (аналитики, технические писатели)
3.2. Есть понимание менеджмента в необходимости хранения, удобного доступа и поиска
3.3. Экономический эффект можно почувствовать быстрее, что опять же увеличивает поддержку сверху. Стало чуть легче жить - и есть поддержка снизу
3.4. В среднем меньше сопротивления и выше скорость освоения технологического инструмента
3.5. Peer to peer обучение (это же тоже KM?) лучше работает, т.к. меньше конкуренция и работы хватает на всех: миддл разработчик охотнее подскажет джуниору и поделится какими-нибудь приемчиками, чем торговый представитель временно стажирующемуся у него новичку.
3.6. Специфика в людях, в разработчиках, в объеме неявных знаний, которыми их сложнее мотивировать делиться, потому что управление знаниями - это про людей. А разработчики - уникальные снежинки, знания очень сильно наслоены на процессы, одни и те же термины в компаниях могут отличаться из-за контекстов. Но специфика в мелочах, никакого кардинального отличия нет.
3.7. Очень хороший ответ был: «Разные отрасли просто более толерантны к отступлениям от лучших практик в одних областях, и менее - в других. То есть если ставить вопрос как "Можно ли в ИТ в вопросах управления знаниями забивать безнаказанно на то же самое, что и в животноводстве?", ответ будет "Нет, нельзя". Но если вопрос звучит как "можно ли правильно применять одну и ту же методологию в ИТ и в животноводстве, с успешным результатом", то ответ будет "Да".»
4. Требования «комплексности»/междисциплинарных знаний. «Как правило, сами знания в ИТ гораздо сложнее. Соответственно, и управлять ими сложнее, нужны другие инструменты (но это сами ИТшники редко осознают)»:
4.1. Очень хороший пример, привожу дословно. «Я работаю в компании – ИТ-интеграторе CAD. Сейчас в эту область нагромождаются IoT (датчики везде), дополненная реальность (т.к. уже сейчас такая документация), иск. интеллект (потому что предиктивная аналитика) и т.д. Да, это все очень сложно, причем нужны междисциплинарные знания всем».
4.2. Вот еще один пример про «потолок понимания»: «В автомобиле тысячи деталей. Его делают огромные коллективы долгие годы. Столько же «строительных блоков» в какой-нибудь средней программке, написанной коллективом из десятка разработчиков. Они его еще и непрерывно переписывают. Код на порядки сложнее любых штук из реального мира. И он очень быстро упирается в пределы человеческого мозга по осознаваемости всей этой фигни». Специально ничего не менял. Там дальше как раз было еще и про то, что весь мир – это линейный рост знаний, а ИТ – нелинейный. И его не отрегулируешь документированием – затраты станут неподъемными…
Все, достаточно. Дальше вытягивать крупицы нового уже стало сложно, - прекращаю ковыряться в новых комментариях.
Итого: посыл для СТО точно есть и сформулирую его в своей презентации, ну, и в одном из следующих постов.
А отличия управления знаниями в ИТ… При наличии общих рамок, которые можно «запихнуть», например, в новый стандарт, применение конкретных процессов в конкретной компании будет свое. Как показали ответы многих людей, основная специфика разработки продуктов в ИТ, – это комплексность знаний и скорость устаревания знаний с одновременной необходимостью сохранять «для потомков» самые важные из них. Т.е. адаптируйте «типовые процессы» под эти и, наверняка, другие требования – и будет счастье. Тем более, что многое в компаниях уже есть. Хоть и не называется управлением знаниями.
Владимир Баронов
