Как всегда выполнить изначально установленные планы не удалось:-).
Поэтому продолжу рассказ о разработке ПО. Несколько слов о численности программистского коллектива.
Хочу вас предупредить, что дальше речь пойдет об организации разработки проприетарного ПО. Разработка свободного ПО организуется совсем по другому.
Обычно более менее сложное ПО профессионального уровня разрабатывается программистскими коллективами. Программистские коллективы бывают простыми и иерархически организованными.
Простые программистские коллективы обычно состоят из группы программистов в составе 1-7 человек и управляются руководителем проекта.
Иерархически организованные группы состоят из основной группы, наиболее квалифицированных программистов проекта, численностью от 2 до 7 человек, напрямую управляющуюся руководителем проекта. Каждый член этой группы получает задания от руководителя проекта и как правило отвечает за реализацию крупной функциональной части проекта (подпроекта).
Обычно у каждого члена основной группы проекта есть в подчинении своя группа программистов от 2 до 7 человек.
В свою очередь на крупных проектах у каждого члена этой группы может быть своя группа программистов численностью от 2 до 7 человек (второй уровень иерархии разработчиков проекта). Каждый программист на этом уровне иерархии, отвечает за разработку как правило своей более мелкой функциональной группы программ.
Некоторые из них имеют свои группы программистов (третий уровень иерархии разработчиков). Все программисты на этом уровне иерархии заняты разработкой одного или нескольких функциональных программных модулей.
В свою очередь у постановщика задач, на сложных проектах, может быть своя группа разработки (от 2 до 7 человек), а иногда даже второй уровень иерархии разработчиков ( от 2 до 7 групп, численностью от 1 до 7 человек каждая). Но эти люди не считаются программистами.
Численность группы обычно не превышает 7 человек. Потому, что исходя из накопленного опыта разработки, группы численностью более 7 человек плохо управляются.
Реальную численность каждой группы определяет её руководитель.
Количество уровней иерархии в профессиональных программистских коллективах обычно не превышает трех. Потому, что коллективы с большим числом уровней иерархии плохо управляются. Сколько уровней иерархии будет реально решается совместно руководителем проекта и руководителями групп.
Отсюда численность программистского коллективов чисто теоретически не может быть больше 350 человек. На практике она очень часто меньше.
Потому, что:
- на нижнем уровне иерархии всегда присутствует какая-то часть стажеров, которых профессиональными программистами считать нельзя;
- численность коллективов растет медленно, как правило от проекта к проекту. Для того, что бы она стала большой необходимо, чтобы каждый следующий проект был сложнее предыдущего, а это не всегда удается, особенно в условиях рынка.
- наконец в программистских коллективах тоже существует текучка.
Казалось, что никакой особой проблемы тут нет, надо просто соединить два разных программистких коллектива и заставить работать над решением одной задачи. Но не все так просто: во-первых для такого объединения нужно, чтобы с инициативой, объединения выступил человек, пользующийся безоговорочным авторитетом в обоих коллективах, что само по себе бывает не часто.
Во-вторых при таком объединении вступают в игру человеческие амбиции, кто кому больше нужен и кому и сколько надо платить. В итоге все, чего удается добиться при объединении, это пощипать один коллектив программистов в пользу другого.
Увеличиться ли при этом производственные возможности "победившего" коллектива и насколько это сопоставимо с вложенными в объединение средствами - это большой вопрос.
Потому, что каждый программисткий коллектив это живой организм со своей культурой разработки и программирования, а адаптация к другой культурной среде даже при самых благоприятных условиях требует времени, что увеличивает время разработки проекта. При чем пропорционально числу новых работников, привлеченных из вне.
Как же поступают на практике. Обычно в крупных фирмах, разрабатывающих ПО, имеют несколько программистких коллективов разной численности и квалификации. Которые решают несколько задач (разной степени сложности) на которые удалось получить заказ. Как правило все программисткие коллективы такой фирмы исторически выросли из первого программистского коллектива, появившегося на этой фирме. Поэтому все они имеют одну и ту же культуру разработки и программирования. Все сотрудники фирмы находятся в едином зарплатном поле и вопрос о повышении оплаты труда возникает только тогда, когда человеку поручают более сложную или более ответственную работу. Кроме того на такой фирме чаще всего существует и неформальный лидер, который руководит наиболее сложными проектами.
При этом на более сложных (а следовательно более дорогих для заказчика) проектах зачастую оплата на однотипных должностях - выше, чем на более простых.
Разработка любого проекта на начальной стадии требует всего двух человек: руководителя проекта и постановщика. При чем квалификация руководителя проекта зависит от степени сложности задачи, которую предстоит решить!
Это позволяет назначить руководителем проекта, даже человека, который ни когда этим не занимался. Такие решение, как правило зависят от сложившейся на фирме ситуации с заказами и принимаются коллективно советом руководителей всех проектов. Потому, что кандидат на должность руководителя проекта, как правило уже успел поработать на разных должностях со всеми ними. Это позволяет фирме обеспечивать кадровый рост своих сотрудников и выполнять любые работы, которые ей удается получить.
По мере реализации проекта число сотрудников фирмы занятых на проекте постоянно увеличивается, до перехода проекта в стадию завершения. На этой стадии программистская группа работающая над проектом начинает сокращаться. В момент начала нового проекта в группе снова остается только два человека.
Одновременная работа над несколькими проектами дает возможность фирме обеспечивать постоянную загрузку своих сотрудников не зависимо от уровня их квалификации.
И позволяет в случае получения фирмой большого и сложного проекта плавно наращивать число сотрудников задействованых на этом проекте практически без вреда для других проектов.
Такой подход позволяет равномерно распределять стажеров по проектам.
Обычно больше всего такая фирма нуждается в сотрудниках самого низшего звена, потому, что таких вакансий просто больше.
Поэтому наличие хорошой репутации, более высокие зарплаты, регулярное обучение на рабочем месте и связанное с ним продвижение по службе, позволяет относительно безболезненно решать кадровую проблему. Обычно в таких фирмах нет недостатка в желающих поступить на работу.
Следует признать, что хорошему, профессиональному, программистскому коллективу численностью в 350 человек посильно очень многое.
Подумайте сами дневная производительность такого коллектива один человеко-год.
Такой коллектив может создать практически все, что требует Заказчик. От ОС до инструментальной системы любой степени сложности. С прикладными системами несколько сложнее так, как их реализация зависит не только от умения программировать, но и от возможностей технических средств.
Откуда же берётся дикое количество людей работающих, по словам "диванных специалистов Рунета" над разработкой больших программных систем? Прежде всего от того, что "диванные специалисты" сами ни когда ничего подобного не делали! Во вторых в число людей задействованных в создании конкретного программного средства часто включают всех сотрудников создавшей его фирмы: обслуживающий персонал, постановщиков, всех программистов не зависимо от того над чем они конкретно в это время трудились, сотрудников разрабатывающих эксплуатационную документацию, людей занятых сопровождением и продажей ранее разработанного ПО, наконец всех стажеров присутствующих на фирме (количество, которых в несколько раз превышает фактическую потребность в них фирмы, по причине последующего отбора только лучших)!
При таком подходе, легко можно выйти на цифру 4 человека года в день, а это как раз и есть несколько тысяч человеко лет на создание сложного программного продукта так, как такие продукты в среднем создаются 2-3 года.
Теперь несколько слов о процессе отладки ПО.
Обычно отладка ПО производится снизу вверх. Программист тестирует свой модуль перед тем, как сдать его вышестоящему руководителю. Вышестоящий руководитель тестирует, полученное от подчиненного ПО, перед тем, как включить его для комплексного тестирования фрагмента ПО, который разработал он сам. Затем проводит комплексное тестирование, ПО своей разработки и вслучае отсутствия ошибок передает оттестированное ПО своему вышестоящему руководителю. И так до руководителя проекта, который проводит комплексное тестирование всего программного продукта.
Хочу обратить ваше внимание, что как правило комплексное тестирование проводится не на полном комплекте всех модулей программного продукта, а лишь на тех модулях которые готовы к моменту его проведения. Не готовые модули заменяются "заглушками" иммитирующими их работу. Комплексное тестирование обычно проводится в заранее назначенный срок к которому каждый исполнитель должен сдать хотя бы один свой модуль (или следующую его версию). В хороших слаженных коллективах комплексное тестирование проводится раз в неделю. Весь этот процесс называется предварительным тестированием.
Процесс предварительного тестирования завершается финальным комплексным тестированием, который проводится руководителем проекта и в котором участвуют все модули, нового программного комплекса.
После успешного завершения финального комплексного тестирования продукт передается в опытную эксплуатацию.
Как правило к этому моменту разрабатывается и начальная версия эксплуатационной документации. Которая тоже тестируется на этапе опытной эксплуатации.
Опытная эксплуатация проводится с участием постановщика и подчиненых ему групп (если они есть). Тестовые задания обычно готовятся параллельно с разработкой ПО, первое из них составляется еще на этапе постановки, что позволяет уточнить алгоритм работы разрабатываемого программного комплекса. Опытная эксплуатации состоит в проверке работоспособности вновь созданого комплекса на реальных и искусственно созданых примерах эксплуатационных задач. Опытная эксплуатация в современных терминах называется Альфа-тестированием.
Ошибки выявленные в ходе тестирования и опытной эксплуатации немедленно устраняются.
После чего задача поступает в промышленную эксплуатацию. Промышленная эксплуатация обычно происходит на нескольких предприятиях, из числа возможных потребителей программного продукта, квалификации персонала которых - доверяет разработчик. Промышленная эксплуатация происходит в реальных условиях эксплуатации, в течении установленного времени. В современных терминах промышленная эксплуатация называется Бета-тестированием.
Ошибки выявленные в процессе опытной эксплуатации оперативно устраняются обычно руководителем проекта. Все время тестирования программного продукта руководитель проекта считается занятым на проекте.
Освобождается он только после передачи результатов проекта в коммерческую эксплуатацию. Но это не значит, что после этого программный продукт перестает сопровождаться фирмой разработчиком. Программный продукт сопровождается все время пока находится в коммерческой эксплуатации. Все обнаруженные ошибки фиксируются просто некоторые из них устраняются оперативно путем выпуска обновлений, устранение других откладывается до выпуска новых версий этого ПО.
Существует ряд видов ПО, которое тестируется иначе. Это программы алгоритм работы которых формируется случайным образом, обычно это компьютерные игры и программы рекализующие алгоритмы ИИ. В этом случае составлением тестовых заданий нельзя проверить все возможные варианты развития событий, а более качественное тестирование возможно только путем многократного поэтапного выполнения программного продукта под наблюдением человека с фиксированием промежуточных результатов. Ошибки на этом этапе возникают не часто, а подготовительной работы много и держать большой программистский штат во время тестирования таких продуктов не выгодно. Для тестирования таких программных продуктов используют специальных людей - тестировщиков. Их задача выявлять и фиксировать ошибки в ПО возникающие в процессе его многократного выполнения. После чего передавать собраную информацию об ошибке программистам для устранения.
В процессе коммерческой эксплуатации программный продукт попадает в руки эксплуатационщиков. Они готовят исходные данные, запускают в нужное время исполнение задачи, и применяют полученные результаты. Раньше в этом процессе участвовали операторы подготовки данных (которые переносили данные с бумаги на машинные носители), с развитием средств вычислительной техники необходимость в них отпала. Сейчас за эксплуатацию программных продуктов обычно отвечают ответственные сотрудники иногда в зависимости от задачи их бывает несколько, в этом случае среди них назначают старшего.
Сегодня в этой области ИТ появилось еще три интересных специализации это: DevOps-Инженер, Инженер-Данных (Data Engineer) и Аналитик-Данных (Data Science).
Я не против данных специальностей я просто не согласен с их современной трактовкой в Рунете.
DevOps-Инженер.
На мой взгляд это профессия будущего. Она будет востребована, когда ИТ индустрия вернется к Фре́ймворкам. По моему мнению это обязательно произойдёт рано или поздно. Я жду, что новое поколение Фре́ймворков будет устроенно слегка иначе, чем широко известные машины фирмы IBM (подробно с моими взглядами на эту тему можно ознакомиться в подборке "ЭВМ нового поколения").
Новое это хорошо забытое старое на старых Фре́ймворках фирмы IBM была такая специальность как Системный программист. Системный программист - это человек, который знал все возможности применения и использования, находящейся на ВЦ вычислительной техники, лучше всех. DevOps-Инженер - это новая реинкорнация данной специальности, тем более, что с появлением принципиально других Фре́ймворков людей овладевших всеми возможностями применения и использования новых машин будет очень мало. Вот только сможет ли несовершенная система высшего образования нашей страны их готовить - слишком штучный это товар! Но специальность безусловно нужна и готовить специалистов по ней обязательно надо. Остается вопрос когда, чему и кто будет их учить?
Чем занимались системные программисты на ВЦ прошлого можно узнать в подборке "По волнам моей памяти".
Сейчас DevOps описывают как методологию разработки ПО для внедрения, которой на ВЦ нужна целая группа DevOps специалистов разных специализаций.
Вот как определяют эту методологию в одном из источников в Рунете:
"DevOps — это методика, требующая изменения культуры, внедрения новых принципов управления и использования технологических инструментов. В центре внедрения DevOps находится инженер DevOps, который должен обладать широким набором навыков, чтобы облегчить процесс трансформации. Однако большинству организаций требуется не просто один инженер DevOps, а целая команда специалистов широкого и узкого профиля, тесно сотрудничающих друг с другом для внедрения методов DevOps и улучшения жизненного цикла разработки ПО."
Наверное многое из написаного верно, трудно только согласится с тем, что там, где раньше справлялся один человек - теперь нужна целая команда! На мой взгляд новая техника должна упрощать, а не усложнять процесс.
Но с учетом того, что на ЭВМ Нового Поколения (ЭНП) я жду несколько серьезных инноваций, с наличием команды в которой, каждый отвечает за определенное направление использования программно-технических средств можно согласится. Первая из таких специализаций это:
Инженер-Данных (Data Engineer)
Как вы наверное уже догадались для меня это тоже специализация будущего. Сейчас её позиционируют, как специалиста по сбору и подготовке данных для Аналитика-Данных я же вижу эту специальность несколько иначе.
Дело в том, что на мой взгляд ЭНП должна иметь несколько принципиально новых устройств ввода-вывода и совершенно другую систему организации и хранения данных.
В этих условиях будет интересно иметь на ВЦ специалиста, который бы знал структуру хранения и использования данных в ЭНП и имел навыки доступа к данным на всех уровнях представления включая физический, таким специалистом я и вижу Инженера-Данных (Data Engineer).
Вместе с этой специализацией на ВЦ интересно иметь специалиста по работе с Ассемблерами на ЭНП их должно быть два. Специалиста по программированию на языке сверхвысокого уровня и языку управления заданиями. Специалиста по безопасности. Специалиста по сетевым и межпроцессорным взаимодействиям.
Что касается Аналитика-Данных то он в эту структуру специалистов будущего не вписывается, по крайней мере на этом уровне.
Аналитик-Данных (Data Science).
Сейчас эту специальность позиционируют, как специалиста, который анализирует данные подготовленные для него Инженером-Данных (Data Engineer).
Я же вижу его роль на ВЦ будущего, как специалиста эксплуатационщика, отвечающего за анализ результатов расчетов в каком-то из специализированных отделов предприятия. И имеющего профильную специальность этого отдела. В общем это не программист, а максимум постановщик новых задач. В своей работе он использует язык управления заданиями (для выборки данных из хранилища ЭНП), язык сверхвысокого уровня ЭНП (для быстрого анализа и проверки идей) и какое-либо специализированное средство Анализа Больших Данных, относящееся к Универсальным Инструментальным средствам ЭНП. На этом его связь с программированием заканчивается и он может целиком посвятить себя анализу больших данных. Таких специалистов на предприятии может быть много минимум один на каждый отдел, а то и несколько.
АНОНС! Сейчас я готовлю новую тему: "Наш ответ "пиндосам"" в которой хочу рассказать о проблемах, которые как я считаю, должны быть решены при помощи ЭНП!
