Григорий Петров: Управление разработкой. О научной дисциплине

[button color=4d61d7 icon=arrow-left-2 url=https://apptractor.ru/develop/grigoriy-petrov-upravlenie-razrabotkoy-spetsifika-razrabotki.html] Предыдущая статья [/button]

Приветствую вас, коллеги.

В прошлой публикации я рассказал о проклятьи нулевой цены копирования и некоторых его неприятных последствиях. Одно из таких последствий – это то, что в нашей области деятельности очень медленно идет накопление знаний. На мой взгляд, намного медленнее, чем в более “традиционных” областях, к примеру, медицине, строительстве или химии. Но это не было бы так неприятно само по себе. В конце концов, существует много других областей человеческой деятельности со схожими проблемами, где каждая следующая задача мало похожа на предыдущую. К примеру, написание художественной литературы, прикладная психология, создание космической техники, нестандартные строительные проекты и так далее, перечислять можно довольно долго.

Какая научная дисциплина стоит за разработкой программ?

Разработка программного обеспечения – это очень молодая область деятельности, ставшая массовой буквально пару десятков лет назад и пережившая взрывной рост. Результаты этого роста впоследствии назвали “цифровой революцией”. Имеем два фактора: очень быстрое развитие и очень медленное накопление знаний. В результате имеем вполне предсказуемый результат: практика разработки ушла в глубокий отрыв как от теории, так и от образования. К какой области знаний относится разработка программного обеспечения?

Это же литература! Скажет филолог. Они пишут программы так же, как пишутся книги. Те же правила декомпозиции, работы с текстом, создание связной картины из фрагментов.

Это инженерное дело! Скажет заслуженный системотехник. Они создают программы так же, как мы создаем приборы и механизмы. Та же функциональная композиция и взаимодействие частей.

Это математика! Скажет математик, ведь программа – это не более чем набор математических функций над числами, а все, что делает компьютер – это складывает и вычитает числа.

Это информатика! Скажет коллега математика, ведь программа – это алгоритмы и структуры данных!

Я очень много лет занимаюсь разработкой и вынужден сказать, что работа современного мобильного разработчика одинаково далека и от информатики, и от математики, и даже от литературного дела. Да, где-то там, в глубине, есть и алгоритмы, и структуры данных, и цифры, и функции, и тексты на языках программирования. Но ими ли занимается разработчик, когда пишет клиент нового удобного сервиса вызова такси для Windows Phone? Он разрабатывает программу в терминах библиотек и фреймворков, модулей и классов, обработки и отправки сообщений, контроля ошибок и сложности кода.

Безусловно, есть много областей разработки программного обеспечения, где основным объектом работы становятся формулы, алгоритмы или текст программ. Разработка компиляторов, физических движков, новых языков программирования, баз данных… Много всего. Но какова эта доля в разработке? Я не знаю. Могу предположить, что значительно меньше половины. На собеседованиях спрашивают алгоритмы сортировки и сходимость рядов Фурье, после чего отправляют создавать веб-сайты или графические интерфейсы к базам данных, где из математики есть только сложение с умножением, а алгоритмы находятся на пять-шесть слоев абстракции глубже создаваемого кода. Большинство программистов используют в своей работе математику и информатику примерно в той же мере, в какой строитель коттеджей использует знания физики и химии.

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

Что все это значит при управлении разработкой? Я выделю основные последствия, хотя на самом деле их намного больше.

Планировать перед разработкой крайне затрудненно

Не только из-за постоянного создания нового, о котором я рассказывал в предыдущей публикации, но и из-за отсутствия накопленных знаний. У большинства разработчиков нет простого и понятного теоретического фундамента, знаний об общих принципах построения прикладного программного обеспечения. Им приходится экспериментировать, пробовать разные варианты решения задачи, ставить эксперименты. Задача менеджера при этом – помогать разработчикам выделять те области, в реализации которых они не уверены, и организовывать небольшие эксперименты, позволяющие убедиться, что придуманное разработчиком новое решение (которое, возможно, через пару лет войдет в быстро рождающиеся и так же быстро устаревающие “учебники”) можно использовать.

Методы управления из других областей плохо применимы

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

Формат колонки не позволяет мне боле растекаться мыслью по древу, поэтому я прощаюсь с вами до следующего выпуска. В котором расскажу про специализацию, buzzword’ы и роль языка программирования в разработке.

[button color=4d61d7 icon=arrow-right-2 url=https://apptractor.ru/develop/grigoriy-petrov-upravlenie-razrabotkoy-spetsializatsiya.html] Следующая статья [/button]