Дэвид Майстер, ИТ и герменевтика

Сначала присказка.

Во-первых, я взялась слушать аудиокнигу "Управление фирмой, оказывающей профессиональные услуги" Дэвида Майстера.

Книга дает возможность разделить нас на категории — в который раз как в первый. Помню одно аниме, в котором каждая серия начиналась с тезиса о том, что "Есть два вида чего-нибудь: ...". Эта книга из той же серии, только автор не ограничился тезисом и развил его на 20 с лишним глав и почти на 10 часов прослушивания. Язык хороший, четкий. Есть повторения мысли, но это скорее фича. Автор, судя по вводной главе, ставит своей целью научить широкий круг читателей тому, что ему уже надоело повторять вслух. То есть он неизбежно снова повторяет то же самое, уже в виде структурированной книги, и потому, конечно, сам себя дублирует, — попробовали бы вы на его месте это отследить.

Кстати, аудиокнига выпущена издательством "Манн, Иванов и Фербер" специально для бесплатного прослушивания на русском языке, так что ищите её в сети и слушайте. Например, вот здесь. Хуже точно не станет.

Дальше для тех, кто прослушал главы 1-4, как и я. А также для тех, кому лень и любопытно.

(Так вот) Во-вторых, несколько дней назад я прочитала первую главу будущей книги Вадима Митякина. Затрудняюсь сейчас сказать про книгу в целом, как и сам автор. Зато первая глава уже готова и её можно прочитать — вот здесь, на специальном сайте. Ссылку размещаю не рекламы, а указания источника ради. Содержимое по ссылке спорное и проходит под грифом "In My Humble Opinion" плюс личный опыт автора.

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

Присказка есть, теперь сказка.

Дэвид Майстер, как настоящий профессионал, старается очертить круг областей деятельности, в которых он консультировал и получил опыт, рассказанный в книге. Опыт обобщается на оказание профессиональных услуг в целом, но примеры предельно конкретные. Речь идет про бухгалтеров, инженеров, архитекторов, инвестиционные партнерства и консалтинговый бизнес в целом, более или менее связанный с производством.

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

В самом начале весь спектр возможных рынков и соответствующих моделей фирм обозначается через 3 точки.

1. Первый полюс – "Мозги". Консалтинга очень много. Производство штучное или почти отсутствует. Стоимость услуг очень высокая, проекты высоко индивидуальные. Риски можно компенсировать только высочайшим профессионализмом и экспертизой отдельных людей. Кстати, для этих ребят есть употребительный английский термин think tanks.
2. Серединка – "Седина". Есть и консалтинг, и производство, причем именно производство является непременным условием для консалтинга. Проекты требуют экспертизы и адаптации, но имеют тенденции и особенности, часто отраслевые, которые повторяются. Риски можно компенсировать накоплением знания в компании и обучением новичков и молодых специалистов, которые смогут выполнять работы, отлаженные экспертами более высокого уровня.
3. Второй полюс – "Процедуры". Консалтинг почти или совсем отсутствует, компания равна производству. Акцент делается на повторяемость ситуаций и предсказуемость операций. Ставка низкая. Риски можно компенсировать высоким потоком проектов и эффективностью, которая будет сохранять низкую ставку прибыльной — а это снова предсказуемость. Люди должны максимально результативно выполнять рутинную работу.

Для юристов, бухгалтеров и архитекторов сам Дэвид Майстер приводит реалистичные, как мне видится, примеры по всем трем вариантам.

А дальше Вадим Митякин экстраполирует эту классификацию на ИТ-отрасль, оперируя своим многолетним опытом работы в ИТ-отрасли и в применении книги Майстера к этой отрасли.

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

1. Вот ребята, которые берут чемоданы "зеленых" за час, причем чаще всего за общение и за создание документов, а также за "элитное" штучное производство. И их услуги покупают. Кто? В основном те, кто хочет сделать свой проект уникальным. Правда состоит в том, что любой проект гораздо проще сделать индивидуальным и неповторимым, чем сделать его оптимально. Действительно уникальных проектов, в которых индивидуальный подход к решению необходим, как воздух, очень мало (относительно общего числа проектов), и они не делаются по модели "заказчик - подрядчик" за редким исключением. В ИТ зашкаливает количество проектов, которые без долгих базаров и нулевой ревизии ошибок пилятся с нуля под соусом "индивидуальный подход" — да, за чемоданы "зеленых". Вот вы, к примеру, вообще помните, что означают слова "индивидуальный подход" или "уникальный проект" в некотором искреннем смысле? Я — смутно. Кроме индивидуальных проектов сюда относятся объективно сложные проекты - инфраструктурно, по объему, по количеству источников информации, участников взаимодействия, репутационных рисков и так далее. На сложных проектах требуется дистиллированный профессионализм, который окупается. Так или иначе, аналог "мозгов" мы нашли. Оставим вопрос о том, кто действительно тянет на "мозги", а кто мимикрирует, — открытым, как форточку в декабре.
2. Смотрим на серединку. Это отраслевые решения, в области которых работаю и я, а именно проектирую b2b-решения. Здесь есть и много b2c, например, интернет-магазины. Тут, в целом, Майстер с Митякиным оказываются правы. Это даже не столько интересный инсайт, сколько банальность. Однако, банальности очень полезно вытаскивать на белый свет и переосмысливать. Посмотрим: средняя цена по рынку колеблется, но организации готовы платить за понимание отраслевой специфики и опыт внедрения конкретных вещей. Решения в сути повторяются. Отметим здесь, что заранее часто невозможно судить, чем новое "типовое" решение будет отличаться от предыдущих. Оставим также за скобками толпы тех, кто не хочет доплачивать за экспертизу и опыт и использует аргументы вроде "да что тут сложного?", "а ваши конкуренты сделали анализ бесплатно", "давайте я сам расскажу вам разработчикам, что делать" и прочие. Эти ребята хотят услуг качества "седины", а платить как за "процедуры". Пусть идут с миром и находят своих подрядчиков.
3. Наконец, надо куда-то определить многочисленные ИТ-производства, которые продают услуги разработчиков. Это и аутсорс, и аутстафф, и подрядчики, которые сидят на количестве часов по фиксированной ставке разработчиков плюс аккаунтинг и управление проектами. Здесь работают многочисленные разработчики и управленцы неопределимого уровня профессионализма, который в целом не надо подтверждать — задачи делаются, и ладно. Ставка либо низкая с расчетом на агрессивный маркетинг, демпинг и недобросовестную конкуренцию. Либо высокая с акцентом на громкие проекты и бренд компании, которые косвенно повышают профессиональную ценность разработчиков, чьи часы продаются. Высокая ставка - скорее про модель "аутстафф" и так называемый Time&Material (английский аналог "рога изобилия"), но не отменяет специализации компаний именно на производстве без консалтинга. В этих компаниях, особенно в "аутсорсингах" и в "подрядчиках", акцент делается на узкую специализацию разработчиков и их способность выполнять совершенно конкретные операции. Это может быть разработка под Битрикс24, которой занимается и наша компания, и это не реклама, а крайне характерная иллюстрация моей мысли. Это может быть разработка, скажем, на React.js, разработка самописных систем определенного толка, разработка решений на мобильные устройства и т.д. Все это, как ни странно, далеко не обязательно предполагает хоть какой-то консалтинг и часто сводится к максимально рутинному управлению проектами. Итак, с "процедурами" тоже разобрались, даже если упомянули не всех.

Хотя Майстер говорит скорее про проекты, я привела примеры организаций, а не проектов. Так делает сам Майстер, вот и я за ним.

А теперь следите за руками.

Когда я даю определение производства, я ничего не говорю про рутинность. Я говорю про:

• Понятный на каком-то уровне алгоритм действий. Нелинейный и ветвистый, но все равно алгоритм. Если не это, то вот это или вон то. Практически невероятно, чтобы решение вовсе не существовало и не было кем-то уже придумано и опробовано. "Вот здесь много вариантов взаимодействия с интерфейсом и необходимо проектирование с прототипами, а вот тут сервера перекидываются файликами и результат достаточно записать в лог." "Вы говорите, уникальный сервис? Я нашел 154 библиотеки, которые делают ровно то же самое." И так далее.
• Возможность разделения труда и специализации. Разные варианты действий предполагают некие поля решений, которые можно поименовать: "дизайн" (инженерный дизайн, разумеется, а не рисование просто красивых интерфейсов), "управление проектами", "управление продуктом", "разработка" и другие. Эти поля решений можно делить и дальше, а также бесконечно спорить, как называются разные поля, потому что их можно чертить и делить на части как угодно. Именно поэтому, кстати, меня периодически ставят в тупик современные практики описания вакансий громкими общими словами (UX-специалист — это кто??), а не по реальному полю решений, которое надо закрыть.
• Результаты деятельности потом используют другие люди. Это могут быть сотрудники клиента, ваши собственные сотрудники, ваши руководители, неопределенно широкий круг лиц (например, вы сделали сайт), инженеры IBM, которые обслуживают ваши сервера, вы сами и так далее. Угроза Перспектива использования хотя бы одним другим человеком означает, что необходимо сделать полезное, реально применимое решение.

А теперь вытащим на белый свет банальность под названием "рутинная работа". Её современный смысл растет из открытия конвейерного производства в Западной Европе в Новое и Новейшее время. Весь смысл конвейера в том, чтобы максимально приблизиться к замене человека машиной. А в чем смысл замены человека машиной? В снижении цены - это да, но гораздо более важным давно стало страхование рисков, связанных с людьми.

Если очень кратко, машина не может уволиться, она железная и прикручена к полу. Люди не железные, и прикрутить их к полу легально нельзя. Но для меня сейчас важнее тот факт, что рутина вообще и машины в частности позволяют избавиться от всех отклонений в технологическом процессе, причиной которых служат люди: человеческая лень, невнимательность, тупость, отчисления в пенсионный фонд и так далее.

Окей, а что есть рутинная работа в ИТ сегодня?

Мой ответ такой — взаимонепонимание планетарных масштабов. Посмотрите сами.

Носитель идеи передает идею переносчикам, которые несут её дальше. Носитель идеи называется "владелец продукта" или просто "заказчик", а переносчики могут называться почти как угодно — от "менеджеров продукта" и "руководителей проектов" до "UX-специалистов", "аналитиков-проектировщиков" и "программиста Васи".

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

• "Владелец продукта";
• "Некий исследователь, пусть он же и проектировщик";
• "Руководитель проекта";
• "Один разработчик";
• "Второй разработчик, потому что первый заболел";
• "Третий разработчик, потому что второй ушел в армию";
• "Снова первый разработчик, потому что он внезапно свободен";
• "Человек, который должен платить деньги всем или всем, кроме владельца продукта".

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

Допустим, что одни и те же слова, картинки, истории, схемы и прочие способы документирования идеи на разных стадиях болезни каждый человек понимает по-своему. Причем это, как правило, выясняется не сразу, потому что в ИТ по умолчанию считается, что написанное кровью на "ТЗ" согласие считается согласием независимо от того, что кто там понял на самом деле. Я почему-то рассчитываю, что с этим тезисом вы согласитесь, особенно если вы старше 25.

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

• иметь мужество признать взаимонепонимание;
• при этом не обидеть собеседника;
• иметь энергию, желание и время заняться выправлением сломанного понимания, которое к этому времени уже заняло какое-то количество часов специалистов. А ведь, как известно, единожды оплаченные часы нельзя продать ещё раз.

На каком-то из этих условий наши персонажи начинают нервничать и часто выбирают неконструктивные пути: замыливание проблемы, игнорирование несостыковок, исправление правок по формальному признаку, взаимные оскорбления, судебные тяжбы и так далее. Если же все поднапряглись и выбрали конструктивный путь, все равно нужно переделывать сделанную работу и терпеть убытки, а мало кто готов это терпеть. Особенно помногу раз.

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

Так насколько ИТ-производство может считаться рутинным и конвейерным? Я думаю, что на 0%. Ни насколько. Собственно говоря, если бы хоть у кого-нибудь получилось найти идеальный процесс в какой-нибудь из областей ИТ на любом уровне градации Майстера "мозги" – "седина" – "процедуры", эдакий вечный двигатель от ИТ, — этот человек бы уже стал верховным правителем Земли. Фундаментальный для ИТ-производства риск различных толкований и взаимонепонимания неустраним даже с помощью конвейерного подхода.

Возвращаясь к Майстеру и подводя итог, хочу сказать вот что. Насколько хорошо и красиво к ИТ-проектам применяется тип проектов и организаций "мозги", настолько же к ИТ неприменим тип проектов "процедура". "Седина" применима со скрипом. Почему? Потому что человеческое общение нельзя стандартизировать, ну никак нельзя, а по-другому передавать идеи для их воплощения мы пока не научились.

Кстати, в равной степени мы не научились начинать ИТ-проекты не с идеи, но это уже совсем другая история.

А вы, коллега-ИТшник, уже изобрели универсальный человеческий способ понять друг друга? Напишите в комментариях.

P.S. Герменевтика - наука об истолковании текстов. Это как раз то, чем ежедневно занимается вся ИТ-индустрия.