Как проектирование программного обеспечения позволяет компаниям экономить средства?
IT предприниматель, эксперт в проектировании программного обеспечения, руководитель с опытом работы более 20-ти лет, выпускник бизнес школы университета Чикаго (Chicago booth) в интервью «РегионСамара» рассказал о проектировании программного обеспечения.
— Что делает ваша компания?
— Занимается проектированием программного обеспечения. Мы работаем на тех, у кого нет соответствующей технологической экспертизы, и тем самым экономим нашим заказчикам много денег.
— Получается, иметь с вами дело – выгодно!
— Проект в разработке софта мало чем отличается от проекта в любой другой отрасли: необходимо, во-первых, придумать, что ты хочешь сделать, во-вторых — реализовать задуманное, и, в конце концов, проконтролировать качество этой реализации. Если провести аналогии со строительным бизнесом, то мы берем на себя четыре роли: разработчика концепции, архитектора-проектировщика, технического заказчика и технадзора.
— Архитектора-проектировщика?! А зачем вообще это проектировать?
— Понимаете, реализация проектов очень похожа в различных отраслях, но отличия, конечно же, есть. Например, в софте есть возможность переиспользования кода, иными словами — возможность продать один и тот же блок нескольким заказчикам.То есть, за создание блока кода платит один заказчик, а потом этот готовый продукт разработчик продаёт еще раз. И не один раз. Это сильно повышает прибыль разработчиков. Почти как в институте: сначала ты работаешь на зачётку, а потом она на тебя.
Чтобы заказчик не попадал в такую историю — когда тебе стараются продать что-то из запасников – лучше иметь третье мнение по вопросу о том, какой софт решает именно твою бизнес задачу.
— Что говорит ваш богатый опыт – часто возникает необходимость в создании нового программного обеспечения?
— В большинстве случаев для решения бизнес-проблем создавать принципиально новое программное обеспечение не требуется. Масса задач решается уже существующими и доступными на рынке продуктами. Их огромное количество в современном мире. Мы, как проектировщики, помогаем бизнесменам найти верный ответ на вопрос, как им решить их бизнес-задачу. А как разработчики — в процессе коммуникации ничего не продаём, делимся идеями без попытки осуществить скрытую продажу. Говоря коротко – мы не “впариваем” нашим клиентам часы разработки.
— Но тогда у вас должны быть очень высококвалифицированные специалисты?
— Так и есть. Сейчас у нас работают люди, каждый из которых имеет двадцатилетний опыт. В профессиональном багаже нашего архитектора, например, — работа в игровой индустрии в США, а также — в крупной российской финансовый структуре, где он строил системы по обработке миллионов транзакций в сутки. Он знаком с различными уровнями нагрузки, которая может приходиться на систему.
Когда говорят наши специалисты, я с ними не спорю. Я просто за ними записываю.
— Можете привести пример одного из самых успешных результатов сотрудничества с вами?
— У нас был зарубежный заказчик, который пытался получить предложение с рынка через реализацию своей бизнес-задачи. Собрав предложения, получил в предполагаемом итоге сумму — около 190 тысяч долларов. А после того, как мы поработали с его исполнителями, наш заказчик подписал контракт на 30 тысяч без изменения функционала. Это, пожалуй, экстремальный пример, но он характеризует результат, который можно получать. Это происходит, в том числе, за счет того, что из проекта, предлагаемого разработчиками, мы выбрасываем элементы, которые могут быть заменены решениями open source. Примером являются сервисы авторизации, которых написаны множество раз для каждого конкретного проекта, в то время как есть аналоги, доступные бесплатно. Такие и похожие решения покрывают необходимые задачи в 98 процентов проектов, с которыми мы сталкиваемся.
— Вы можете оптимизировать любое решение?
— Практически так. Мы все видим, что рынок разработчиков перегрет. Компании — промышленной или в сфере услуг — сложно нанять разработчиков и получить технологическую экспертизу со своей стороны, как заказчику. Даже если ты их нанял, то после того, как проект сделан, этих разработчиков надо увольнять, или придумывать им новую работу.
Удивительно то, что любой другой проект люди реализуют, исходя из идеи, что нужно иметь понимание что именно делают исполнители. И только в области разработки программного обеспечения заказчик почему-то считает возможным полностью положиться на исполнителей, произнося фразу: “Ну вы там напишите техзадание, а мы его к договору приложим”.
По сути, мы сдаем заказчику в аренду свою технологическую экспертизу на время реализации проекта, включая время его взаимодействия с разработчиками.
— Как вы оказались в индустрии?
— Я много лет работал в финансовой сфере, в том числе в нефтегазовой индустрии. Привык смотреть на бизнес как на набор процессов. Моей специализацией была пост-M&A интеграция. Это интересная деятельность. Задача заключалась в том, чтобы переделать процессы одной компании, которую покупала другая компания, и в которой работал я, в состояние, устраивающее моего нанимателя. В общем, я много рисовал всякие диаграммы, и выяснилось, что это сильно похоже на проектирование программного обеспечения.
Я получил хорошее MBA. С большим уважением отношусь к этому образованию, несмотря на известный российские скепсис, будто бы бизнесу нельзя научить. Но на MBA бизнесу не учат. Там учат инструментам, которые позволяют анализировать различную информацию – финансовую, рыночную, информацию о действиях конкурентов. За 12 лет работы финансовым директором я научился не любить консультантов. Однако ирония в том, что сам стал консультантом. Консультирую, выступаю с лекциями на it-конференциях…
— А что лично вы делаете в компании?
— Помимо того, что я начальник, а это требует отдельного времени, моя работа состоит в том, чтобы увязать будущее программное решение с другими бизнес-процессами заказчика. Я – тот человек в нашей компании, который должен отобрать идеи разработчиков, подходящие для решения бизнес-задач. Конечно, двадцатипятилетний опыт в этом сильно помогает. Моя личная экспертиза — в строительной отрасли, ресурсной, в силу базового образования и опыта я неплохо понимаю финансы.
В целом — я отвечаю за отраслевую экспертизу, и, в том числе, за привлечение этой экспертизы. Например, мы делали проект телемедицинской платформы, и для того, чтобы сделать процессы в решении качественными, мы привлекли в качестве эксперта коллегу с опытом работы главным врачом как в муниципальной, так и в частной клиниках. Платформа, которую мы в итоге спроектировали, принималась потом на ура профессиональным медицинским сообществом.
Я снова хочу высказать эту мысль: контуры бизнес-идеи не должны разрабатываться программистами. Наиболее разумное отношения к разработчикам – отношение как к высококлассным строителям, которые должны по проекту выполнить задание. Когда программисты говорят: “У нас есть бизнес-аналитики”, надо держать в голове, что эти бизнес-аналитики получают зарплату у программистов, и, конечно же, будут предлагать решения, максимально увеличивающие прибыль своего работодателя, вспомним пример с сервисами авторизации.
— Agile — это популярно, а вы сначала пишете техзадание, чтобы потом его выполняли разработчики?
— Знаете, как говорят: планирование необходимо, но его не должно быть слишком много. Есть такая управленческая технология разработки ПО, называется “Waterfall”, “Водопад”. Вот там сначала расписывают все детально, “до мышей”, а потом реализуют в формате “шаг в сторону — попытка побега, прыжок на месте — попытка улететь”. Нам это не нравится, потому что это плохо работает. Как метафорично говорят люди, которые имеют опыт применения этой управленческой технологии, «водопад может течь вбок, а в особо сложных случаях даже вверх!».
Разработка ПО — это проекты с пластичными требованиями. А пластичность обеспечивается тем, что требования генерируются человеческими отношениями. Это оценки рынков, оценки пользовательского поведения и пользовательских предпочтений. В сравнении с проектами разработки полезных ископаемых, где геология не меняется десятками тысяч лет, конечно же, проекты ПО более подвижны.
Но у меня есть корпоративный опыт, и я знаю, что для корпоративных заказчиков в чистом виде Agile, а именно — мгновенное принятие решений по изменениям, зачастую не работает. Например, изменение контуров будущего продукта, возможно, потребует изменения бюджета, и во многих корпорациях такое решение требует определенных процедур и шагов. Зачастую его невозможно принять на уровне одного специалиста, который контролирует ход реализации проекта.
Мы пришли к применению разновидности Agile, она называется Agile Feature Driven Development. Этот подход позволяет совместить гибкую разработку с корпоративными практиками принятия различных управленческих решений.
— Ну хорошо, сделали техзадание, и все? Отошел в сторону, как другие консультанты?
— Нет. Мы очень любим проводить тендерные процедуры в пользу заказчика. У меня есть коллега, много лет руководившая службой внутреннего аудита в одной из крупнейших российских корпораций. Она любит повторять известную цитату: “Важно не то, как проголосовали, а то, как посчитали”. Рассказывает про разные чудеса – как, к примеру, ответственный сотрудник может сказать, что это он опечатался, и вместо клавиши с цифрой “три” нажал на клавишу “шесть”, а то, что результат тендера из-за этого кардинально поменялся, ну так извините…
Вот подсчёт мы предлагаем взять на себя заказчику, причем, так, чтобы мы были бы не в курсе ни процесса, ни результата. А мы помогаем расширить круг участников тендера, создать структуру запроса на предложение, в которой поступающие оценки можно сравнивать.
— Ваши инновации, должно быть, меняют рынок разработки? Привносят в его работу больше гибкости, открытости и прозрачности?
— Мы умеем делать управление проектом. У нас есть опыт реализации проекта, в котором одновременно работало 4 команды разработчиков, максимальное число инженеров составляло 33 человека. Команды работали параллельно и не мешали друг другу. Наша экспертиза состояла в том, чтобы сформулировать требования для организации такой работы. Мы умеем делать от имени заказчика двухнедельные, в ежедневном режиме встречи с разработчиками…
Самой важный частью нашей работы я считаю приёмку готового ПО. Мы умеем написать требования, как именно необходимо проверять софт, и организовать эту приёмку на стороне заказчика. Мы видим существующую на рынке практику написания ПМИ (программа и методика испытаний — набор проверочных действий, который должен дать ответ, соответствует продукт своей идее, или нет) силами разработчика, что лично меня немного озадачивает.
— Озадачивает, потому что в этом случае заказчик, который платит деньги, поручает исполнителю написать программу проверки качества работы этого же самого исполнителя? Какой выход из этого тупика вы можете предложить?
— Простое решение выхода из этого тупика состоит в том, чтобы проверку делал кто-то другой. В строительной отрасли такой подход закреплен законодательно. Хорошо, когда заказчик понимает содержание и суть проверок. Мы всегда помогаем заказчику создать серию необходимых тестов в формате, который понятен менеджменту заказчика.
— А вы что-то делаете с искусственным интеллектом? Сегодня это горячая тема…
— У меня была возможность поговорить с преподавателем кафедры факультета вычислительной математики и кибернетики МГУ, который любезно разрешил мне посещать его лекции по машинному обучению и по глубокому обучению. Я целый год просидел за партой рядом с двадцатилетними студентами. Чтобы проверить результат своих усилий, принял участие в IDAO 2020. Итог такой: я занял 42-е место из, приблизительно, полутора тысяч участников. Иными словами, теперь я своими руками умею делать модели, и понимаю, о чем речь.
Мы делали проект для финансового института, и я могу сказать, что для проектов с применением искусственного интеллекта работают те же самые принципы, что и для любого другого софтверного проекта. Не надо заниматься велосипедостроением – строить свои модели и пытаться конкурировать с технологическими гигантами. Корпорация Google предоставляет великолепные модели для использования, причём, их можно использовать локально в контуре заказчика. Сейчас основная задача, которую требуется решать, – это работа с собственными данными.
Мы, как эксперты, можем помочь заказчику выбрать те элементы его бизнес-процессов, в которых применение различных моделей будет наиболее эффективным. Конечно, мы помогаем организовать сбор и хранение данных, чтобы это все всегда работало. А к моделям нужно относиться, как к выбору любого другого технологического решения. Целесообразно строить систему, в которой сегодня вы, допустим, используете модель от Google, завтра — от OpenAI, а послезавтра – от Facebook. Ваше решение должно быть гибким, иметь возможности использовать наиболее современные модели, которые должны быть заменяемыми…
