О проблемах малоразмерной заказной разработки и их решениях¶
Введение¶
Всю свою практику я предпочитал обходить стороной рынок заказной разработки, т.к. совокупность противоречивых интересов делает её не самым комфортным местом для самореализации специалиста.
Но в силу жизненных обстоятельств, мне пришлось какое-то непродолжительное время поработать в ГКУ ИАЦ и обрести возможность глубже ознакомиться с проблематикой в этой области.
Здесь и далее я буду использовать информацию исключительно из открытых источников, либо добровольно предоставленную мне представителями подрядчиков как физическому лицу.
Чем меня лично привлекла эта тема, так это тем, что эта ниша является отличной отправной точкой для бизнес-дебюта технических специалистов, позволяющей сменить статус наёмного работника на работодателя. Думаю, об этом задумывались многие специалисты старше 30 лет.
Одной из целей этого доклада является попытка приоткрыть техническим специалистам новые финансовые возможности. В то время, как квалифицированный архитектор зачастую выгорает на рабочем месте за зарплату в 500 тыс. руб. (усредненные данные нескольких человек), на коммерческом рынке он может заработать в 20 раз больше (по данным нескольких подрядчиков), и при этом предоставлять рынку высококачественную и более чем конкурентоспособную продукцию по привлекательным ценам.
Казалось бы, должны образоваться толпы желающих, но этого не происходит, и рынок малоразмерной разработки испытывает дефицит квалификации. Эти причины мы попробуем отыскать и попытаемся найти им решение.
Почему я считаю важным решение проблем малоразмерной заказной разработки? Казалось бы, это так мелочно. Ну что может сделать маленький подрядчик, подобный пчелке на теле слона?
💬 Опылители вносят непосредственный вклад в обеспечение продовольственной безопасности. По данным специалистов по вопросам пчеловодства Продовольственной и сельскохозяйственной организации (ФАО) ООН, треть мирового производства продуктов питания зависит от пчел.
Проблемы¶
Я провел ряд встреч с участниками всех сторон рынка: с исполнителями, с заказчиками и с инвесторами. И выделил следующие группы проблем.
Со стороны заказчика¶
Низкий уровень качества услуг
Неоправданные ожидания
Систематический срыв сроков разработки
Систематический перерасход бюджета
Огромный разброс ценовых предложений подрядчиков
Непонимание критериев выбора подрядчика
Высокая доля авантюризма и шарлатанства среди подрядчиков
Склонность подрядчика к переусложению и к завышению стоимости решения
Отдельно стоит выделить объективные рыночные предпосылки, склоняющие подрядчика к переусложнению решения, затягиванию сроков разработки, размыванию внутреннего качества ПО. На эту тему высказывались даже такие светила мировой ИТ-архитектуры, как Gregor Hohpe, в статьях:
💬 "System Integrators...
Generally, more complexity means more work and thus more revenue. This isn’t necessarily intentional or devious - self-preservation is at the very base of Maslow’s Hierarchy of Needs.
Consultants
While the SIs are the enterprise’s helping hands, consultants are the hired brains. They solve complex problems and devise IT strategies. But they also want to remain employed, so they might solve a problem almost completely, leaving just enough for more work to be done. Self-preservation equally takes hold here. In consultant vernacular this is called scoping or expectation management."
—"Here's why enterprise IT is so complex" by Gregor Hohpe
💬 "Don’t outsource thinking. Keep control of your IT in house and match vendor offerings against your plan, not the other way around."
—"Here's why enterprise IT is so complex" by Gregor Hohpe
💬 "If you let externals or vendors define the strategy, you'll be surprised how well their products fit “your” strategy... Your own strategy has to be the benchmark against which you measure products and services that you buy. Without that baseline, your IT management will resemble kids running down the supermarket aisle, tossing whatever they like into the cart. Come to think of it, I have seen more than one IT that does resemble such a shopping cart..."
—"Don't Outsource Thinking" by Gregor Hohpe
А Mathias Verraes и вовсе сказал, что:
💬 "We have created outsourcing farms, that produce legacy at the speed of typing. It’s legacy as a service (LaaS) [Quote by Pieter Hintjens]"
Matthew Skelton поддержал его в этом утверждении.
И даже сам Edsger W. Dijkstra говорил:
💬 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
—Edsger W. Dijkstra, 1984 "On the nature of Computing Science" (EWD896)
Еще несколько точек зрения:
💬 "Indeed, GM is well known for its excellent software. A story: some years ago, I met up with the GM CIO (now long gone) who was proudly asserting that to cut costs GM was outsourcing ALL software development. I advised him, in very polite terms, just how stupid was that idea."
💬 "Almost every outsourcing or service provider contract drives toward 100% utilization of the resources."
—Michael Nygard, в ответ на "Striving to ensure that no resource be idle is the biggest generator of waste." — Eli Goldratt
💬 "In my experience, IT outsourcing can work well in two situations:
Where the outsourced capability is provided as a service with defined APIs and SLOs - ongoing.
Where the outsourced capability is provided as a TeamTopologies Enabling team - temporary."
💬 "Every org I talked to that relies heavily on outsourcing mentioned similar problems of lack of alignment of purpose, lack of trust, time to onboard, and (consultant/contractor) turnaround time as blockers to fast flow, ownership, performance, etc."
Со стороны инвестора¶
Невозможность прогноза и контроля рисков
Отсутствие прозрачности расходования средств
Высокая доля прогоревших вложений
Утрата доверия к подрядчику
И в то же время эта ниша продолжает привлекать инвесторов своей высокомаржинальностью.
Со стороны подрядчика¶
Квалификационно-кадровый голод, вызванный невысоким уровнем карьерной привлекательности его вакансий на рынке труда для карьерных перспектив квалифицированных специалистов
Захламленность рынка знаний низкокачественными тренингами и курсами, препятствующими поиску эффективных программ повышения квалификации специалистов
Непонимание способов адаптации гибких методологий разработки под модель бюджетирования (особенно при работе с гос.заказом)
Отсутствие опыта контрактования с гос.заказчиком
Чрезвычайно низкая точность планирования разработки
Низкий уровень качества разрабатываемого ПО, который влечет за собой существенное и неконтролируемое снижение темпов и затягивание сроков разработки
Текучка кадров, возникающая вследствии демотивации специалистов низким уровнем внутреннего качества ПО и психологическим напряжением под воздействием давления сроков
Малый запас финансовой устойчивости для постоплаты, который формирует потребность в привлечении инвестиций
Недостаточный уровень архитектурной работы, в результате чего выявленные в ходе эксплуатации дефекты требуют дорогостоящего устранения
Недостаточный уровень архитектурно исследовательской работы (дивергентной фазы принятия решения), в результате чего подрядчик нередко не подозревает о существовании более экономически целесообразных решений
Отдельно стоит выделить проблему захламленности рынка знаний. Знания превратились в предмет торга, а значит, сиюминутная жажда наживы участников рынка влечет за собой количественный рост в ущерб качеству тренингов. Даже Gregor Hohpe высказался по этому поводу:
💬 "There's a definite Dunning-Kruger effect for authors. The people who hold a ton of knowledge hesitate because they find their insights "obvious" or "nothing special". Then you have people who write a lot but do little real work that they could base their writing on..."
Появилось большое количество бутафорных преподавателей, культивирующих мечтательство, оторванное от реальной практики. А между тем, ключевым отличием знания от мнения является именно эмпирическая проверяемость и непротиворечивость.
Со стороны технических специалистов¶
По результатам опроса, каждый пятый специалист заставляет себя работать через силу и регулярно испытывает желание уволиться, лишь каждый третий доволен условиями работы
Застой, выгорание
Недостаточно возможностей для полноценной самореалицации
Демотивация от низкого уровня внутреннего качества ПО. Руководство не выделяет ресурсы на устранение техдолга.
Безорганизованность процессов разработки
Противоречия¶
Выглядит пугающе, не правда ли? В студенческие годы мне попалась книжечка психолога Джона Хейдера "Дао Лидера". Она представляет собою современное руководство для руководителей на основе древнекитайской "Дао дэ цзин" Лао-Цзы, в основе которой лежит диалектическая философия, утверждающая, что всякое противоречие приводит к синтезу новых форм. А значит, нужно не бояться этих противоречий, а выявлять и умело использовать их для поиска новых решений.
На практике такую способность хорошо демонстрируют Kent Beck и Jeff Sutherland, и это тянет на отдельную серию докладов, поэтому мы не будем сейчас углубляться и ограничимся простым упоминанием этого факта.
Учебные центры¶
В мире заказной разработки особняком стоят компании, имеющий замкнутый цикл подготовки своих специалистов. Эмпирическая проверяемость учебного материала поддерживает высокий уровень эффективности самого материала. Чем это можно объяснить?
Это можно объяснить тем, что они используют комплексное решение проблемы. Предметом торга выступают не знания сами по себе в изоляции, как кот в мешке, внешне ничем не отличимые от заблуждений, а конкретное улучшение внутреннего качества ПО и повышение темпов разработки.
Подобное объединение обязанностей использовал и Jeff Sutherland, объединив в роли Product Owner две обязанности, чтобы скомпенсировать перекос в пользу одной из них:
💬 "One common approach is to hire a project manager to oversee the team's day-to-day work. The project manager does the work that management may feel is too important to ignore but not important enough to distract from their own pressing agendas. Though this is very common—almost ubiquitous — the approach in fact slows product delivery and may reduce quality and profitability. First, the organization is building a product rather than carrying out a project. When project development completes, the product is still in the field and questions of maintenance and added feature development find only awkward answers. Organizationally separating product creation from ongoing development ("maintenance") creates many problems. Secondly, the company rarely gives the project manager responsibility for value such as ROI or net present value (see Value and ROI), so his or her incentive is to deliver as fast as possible within the financial constraints. Without this responsibility, the project manager is more likely to make short-term decisions with long-term consequences, and short-term decisions tend not to have positive long-term consequences."
—"A Scrum Book: The Spirit of the Game" by Jeff Sutherland, James Coplie, chapter "11 Product Owner"
Подобно тому, как Product Owner отличается от Project Manager тем, что отвечает не столько за написание плана, сколько за ROI, так и учебный центр должен отвечать не за написание текста учебных курсов, а за реальный рост эффективности команды.
Давайте подумаем, какие еще изменения могут произойти в таком случае.
Шарлатаны на рынке знаний не могут позволить себе пойти на такой шаг, а значит, это качественно выделит эффективные учебные программы. Заказчику станет очевидно кто есть кто.
Многие технические специалисты обходят вакансии малоразмерных подрядчиков стороной потому, что это не повышает их ценности на рынке труда, предпочитая вакансии высокотехнологичных компаний, наличие которых в резюме придает ему признаки гарантии обретения релевантного опыта. Обретение релевантного опыта. Иными словами они выбирают не столько место работы, сколько место учебы. Вхождение малоразмерного подрядчика под патронаж авторитетного учебного центра повышает степень привлекательности его вакансий точно так же, как повышается степень привлекательности неизвестного мне отеля в незнакомом мне городе, если он входит в состав известной мне франчайзинговой сети.
То же самое справедливо и к Заказчикам и к Инвесторам. Когда мы покупаем облигации, мы не изучаем всю финансовую документацию кредитора - мы просто смотрим на его рейтинг, присвоенный аккредитованным рейтинговым агентством. А кто знает реальный потенциал компании лучше учебного центра, отвечающего за рост его эффективности? Такой центр мог вы выполнять не только учебные, но еще и надзорные функции в отслеживании прогресса реализации средств Инвестора, выявляя угрозы на максимально ранней стадии и купируя их оказанием своевременной помощи.
Сняв напряжение с инвестора и восстановив доверительную обстановку, решается проблема малой финансовой устойчивости малоразмерного заказчика для контрактования на условиях постоплаты. Это, в свою очередь, устраняет стимул заказчика к необоснованному переусложеению и завышению стоимости решения.
Тут, правда, возникает вопрос угроз, исходящих из мнополизма на компетентность, и к этому вопросу мы еще вернемся.
Мне известно огромное количество случаев, когда стремящийся к развитию специалист был вынужден уволиться только потому, что работодатель не предоставлял ему возможности для реализации полученных знаний, вынуждая его копаться в спагетти-коде. Зачастую это сопровождается невысоким уровнем квалификации команды. А между тем, код - это рабочее место программиста, условия его работы. Не думаю, что найдется много желающих работать в условиях, напоминающих помойку.
Инкубаторы¶
Почему мы доверяем программному обеспечению от Apache Software Foundation (ASF)?
Придание проекту статуса первичного (Top-Level Project (TLP)) проекта Apache, после успешной проверки в "инкубаторе", означает, что продукт и развивающее его сообщество подтвердили способность следования принципам разработки Apache и теперь готовы для самостоятельного существования, не требующего дополнительного надзора.
Подробнее об инкубаторе: https://incubator.apache.org/
Подробнее о принципах: https://apache.org/theapacheway/
Похожую модель реализуют некоторые известные мне крупные Заказчики в порядке частной инициативы. Они буквально "выращивают" своих подрядчиков, организуя им наставничество, обеспечивая их учебно-методическими материалами, разрабатывая и внедряя им модель управления жизненным циклом разработки, управления требованиями, документирования архитектуры, предоставляя эталонно-демонстрационные приложения, стандарты кодирования, а так же предоставляя комплекс программного обеспечения для планирования, управления процессами разработки, управления и автоматизированной трассировки требований, документирования архитектуры, автоматизации тестирования, интеграции и сборки, и пр.
Кроме того, они существенно повышают конкурентность ценообразования путем распределения подсистем проекта для реализации между подрядчиками в соответствии с уровнем их подготовленности. Производимый эффект такой же, как от сплита акций на фондовом рынке.
Однако, у Incubator ASF есть одна особенность:
💬 Rather than detailed rules and hierarchical structures, ASF governance is principles-based, with self-governing projects providing reports directly to the Board. Apache Committers help each other by making peer-reviewed commits, employing mandatory security measures, ensuring license compliance, and protecting the Apache brand and community at-large from abuse.
В основу сообщества положена система достижений участников сообщества, известная как Меритократия.
💬 When the group felt that a person had "earned" the merit to be part of the development community, they granted direct access to the code repository, thus growing the group and increasing its ability to develop the program, and to maintain and develop the software more effectively.
We call this basic principle "meritocracy": government by merit.
Монополия на компетентность¶
Принципы ASF формируют саморегулируемое сообщество, что в определенной мере устраняет озвученную ранее проблему монополии на компетентность.
Мы все помним недавний публичный баттл между авторитетной организацией McKinsey, написавшей статью "Yes, you can measure software developer productivity", и известным авторитетом Kent Beck, одним из ключевых основоположников Agile, Refactoring, TDD, Design Patterns, написавшим ответ в двух частях:
Это далеко не первое противостояние в авторитетных кругах, достаточно вспомнить массовую реакцию известных авторитетов на статью от Uber "Introducing Domain-Oriented Microservice Architecture".
Все это говорит о том, что ситуация, в которой кто-то, пусть даже очень авторитетный, присваивает себе монополию на компетентность, несет в себе риски сдерживания развития профессионального сообщества.
Что если эта монополия попадет не в те руки? Тогда она легко может превратиться в монополию на бескомпетентность.
О квалификационных тестах¶
По этой же причине в профессиональном сообществе сложилось скептическое отношение к квалификационным тестам различных аутсорсинговых бирж, примитивность которых далеко не всегда отражает реальный уровень квалификации. Тем более, что на просторах интернета гуляют ответы на эти тесты, а участники бирж научились эти тесты обходить, вмешиваясь в работу скриптов html-страницы.
Квалификационные тесты являются, скорее, ограничителем развития (тест пройден - дело сделано), а не стимулятором развития. Они "притягивают" развитие к целевому уровню, а не отталкивают развитие от отправной точки вперёд, как это делает, например, система спортивных званий, где уровень мастерства спортсмена определяется относительно известного (доказанного) уровня мастерства других спортсменов (путём сравнительного анализа).
Например, получить I разряд в Самбо можно только одержав в течение года 10 побед над спортсменами II разряда (из них 3 чисто) или 5 побед над спортсменами I разряда на соревнованиях любого масштаба.
Наукоёмкость ИТ-индустрии не имеет ограничений, как и спорт. Это наводит на мысль о том, что методы выявления уровня мастерства не должны ограничиваться монополией экзаменатора на компетентность.
О рейтингах¶
Уровень дохода подрядчика не всегда коррелирует с реальным уровнем его квалификации (Джордж Акерлоф описал эту проблему в классической статье «Рынок лимонов»).
💬 "Джордж Акерлоф в классической статье «Рынок лимонов» на примере рынка подержанных автомобилей показал, как асимметричность информации может привести к краху рынка [3]. Предположим, существует две категории подержанных автомобилей: «лимоны» (автомобили плохого качества) и «персики» (автомобили хорошего качества). Предположим далее, что владелец каждого «лимона» готов продать его за 1000 долларов, тогда как каждый потенциальный покупатель готов заплатить за «лимон» 1500 долларов. Допустим, владелец «персика» готов продать его за 3000 долларов, а потенциальный покупатель готов заплатить за него 4000 долларов. Если бы качество автомобилей было с самого начала очевидным для каждой из сторон, тогда рынок работал бы должным образом. Все автомобили можно было бы продать: «лимоны» — по цене от 1000 до 1500 долларов, а «персики» — от 3000 до 4000 долларов.
Но что если каждый продавец знает о качестве своего автомобиля, а покупателям известно только то, что на вторичном рынке половина автомобилей — «лимоны», а другая половина — «персики»? Если бы автомобили этих двух категорий предлагались на продажу в равной пропорции, каждый покупатель был бы готов заплатить не более чем ½ × (1500 + 4000) = 2750 долларов. Владелец, который знает, что его автомобиль относится к категории «персиков», не захочет продавать его по этой цене. Следовательно, на рынке будут продаваться только «лимоны». Покупатели, зная об этом, будут предлагать максимум 1500 долларов. Рынок «персиков» полностью прекратит свое существование, хотя покупатели и готовы платить за «персики», качество которых может быть доказано, вполне приемлемую для продавцов цену. Это полностью разрушает чрезмерно оптимистичную интерпретацию рынка, которая состоит в том, что рынок — это самый лучший и самый эффективный институт для ведения экономической деятельности."
[3] George A. Akerlof, “The Market for ‘Lemons’: Quality Uncertainty and the Market Mechanism,” Quarterly Journal of Economics 84, no. 3 (August 1970): 488–500.
—"Теория игр. Искусство стратегического мышления в бизнесе и жизни" / Авинаш Диксит и Барри Нейлбафф ; пер. с англ. Н. Яцюк. — М. : Манн, Иванов и Фербер, 2015.
Обратите внимание на:
💬 "Если бы качество автомобилей было с самого начала очевидным для каждой из сторон, тогда рынок работал бы должным образом."
На аутсорсинговых биржах часто применяется система рейтингов, но этот рейтинг зачастую отражает не уровень квалификации, а уровень лояльности исполнителя, ибо если бы заказчик был способен оценить компетентность, то он не обращался бы за этой компетентностью на биржу.
На этом фоне качественно выделяются рейтинговые системы экспертных сообществ, уровень экспертности участников которых определяют сами же эксперты.
В качестве некоторых известных мне примеров можно привести:
и др.
Причем, наилучшего результа достигают системы, купирующие Эффект Даннинга-Крюгера, путем ограничения влияния участников с недостаточным уровнем в отношении участников с превосходящим уровнем. Наверняка вы наблюдали на практике, с какой самоуверенностью начинающий разработчик доказывает свою правоту на Code Review более опытному разработчику.
Вопрос достижения объективности ранжирования и исключения недобросовестной конкуренции является достаточно сложной темой, поэтому мы погружаться в неё не будем, отметив лишь, что решения существуют, и этим занимается раздел математики "Теория Игр".
Я начал разработку Open Source проекта grade, призванного решить эту проблему.
Артели¶
Инженерный центр может заниматься не только выращиванием малоразмерных подрядчиков, но и их формированием.
Он может содержать банк данных технических специалистов, как готовых перейти в категорию работодателей, так и готовых к найму ради расширения собственного кругозора, чтобы расширить свой кругозор и спастись от выгорания на основном месте работы.
Startup Emulator¶
Хочу обратить внимание на проект моего товарища https://www.startupemulator.com/
Функции у этого проекта учебные, но продукты он создает реальные. В этом проекте опытные менторы на практических задачах передают свой опыт и знания новичкам.
Что мы имеем¶
Получается ситуация, когда рынок сбыта есть, инвестиционные средства есть, компетенции есть, все по отдельности есть, но между собой это работает не очень.
Квалифицированные специалисты боятся выходить на коммерческий рынок в силу ряда когнитивных искажений, таких как
и др.
Образовавшиеся пустоты нередко заполняют шарлатаны, пользуясь все тем же недоверием сторон.
Если будет существовать организация, в которой квалифицированный специалист сможет получить поддержку по недостающим компетенциям и наставничество в своих первых шагах в бизнесе, то это может устранить боязнь грамотных специалистов выходить на коммерческий рынок, что может обеспечить приток востребованных компетенций и качественное преобразование рынка малоразмерной заказной разработки.
Послесловие¶
Среди организаций, которые могли бы осуществить такое преобразование рынка заказной разработки, мог бы выступить сам город Москва, являющийся одним из крупнейших заказчиков, и создающий инвестиционные фонды. Или же в бизнес-среде найдутся заинтересованные стороны.