Разработчики программ давно пытаются научиться сооружать программы из готовых компонентов так же, как собирают элементы компьютеров из электронных компонентов. Получается не идеально, конечно же, но тем не менее, такие принципы как information hiding и loose coupling действительно работают и очень сильно облегчают жизнь при разработке больших систем.
На самом деле, как инженер, я прекрасно понимаю, что во многом именно за счет использования подхода “я знаю, как к тебе обращаться и как получать от тебя результат, но меня не интересует, как ты это делаешь” удается справится со сложностью разработки ПО.
Управление коллективами, работающими над большими и сложными проектами, вряд ли можно считать более простой задачей, чем разработку ПО (хотя здесь возможны горячие споры). Тем не менее, в управлении принцип information hiding нарушается сплошь и рядом.
“А чем у тебя занимается Ваня Иванов?”
“А почему я не вижу планов загрузки Васи Васильева?”
“А кого ты привлекаешь к решению проблемы X и почему там нет Феди Федорова?”
Не понимаю. Т.е. наблюдаемая мной объективная реальность заставляет меня принять тот факт, что в управлении задействованы какие-то другие механизмы и принципы. Но вот понять их я пока не могу. Подозреваю, что почти двадцать лет инженерной деятельности сказывается здесь самым негативным образом.
Может потому, что у людей нет тех же характеристик, как у программных блоков?
ОтветитьУдалитьНапример, если определённый код на заданном процессоре обработает файл нужного размера за X времени, то вдвое больший файл, потребует 2X.
А человек вчера проделавший работу Х, сегодня может быть в плохом самочувствии и выполнить только 0.5Х.
Программа работает - прогрессбар отображает.
Человек работает - состояние дел не всегда очевидно.
Программный модуль имеет документацию, и выполняет известный набор задач.
Человек мог растерять навыки или приобрести новые, а на лбу это не написано.
Вот если недостатки человека в сравнении с программными сущностями, дополнить толковым инструментом постановки задач, контроля хода работ и т.д. то и с персоналом можно будет работать пользуясь принципами инкапсуляции.
@ОтецСергий
ОтветитьУдалитьСначала отметем постулат о толковых инструментах. Инструменты за вполне приемлимое время создаются под любой процесс. Так что задача не в том, чтобы найти инструмент. А в том, чтобы сначала выстроить процесс, и уже затем облегчить его за счет нужного инструмента.
Далее на счет обозримости. Да, деятельность программиста не сильно прогнозируема (особенно если он работает над новым проектом). Однако, ход его работы лучше всего видит его непосредственный начальник. Чем выше уровень иерархии, тем хуже. Начальник подразделения из 10 человек еще может следить за каждым из них (пусть и с трудом). Начальник, у которого в подчинении 50 человек уже видит лишь пеструю картинку. Когда под человеком 100 подчиненных, ситуация еще хуже. Когда 200...
Тем не менее, даже те, под кем ходят 200 человек, все равно хотят видеть такие процессы, при которых строится прозрачная отчетность по деятельности каждого из них.
Другой аспект проблемы. Распределение ресурсов для выполнения каких-то работ. Почему-то у начальства есть желание видеть список ресурсов, которые будут выделены под задачу. Сначала в обезличенном виде (просто по ролям -- один ведущий программист, два программиста, один тестировщик, один техписатель, один внедренец). Затем с фамилиями и датами начала их работы над проектом.
Хотя я не понимаю, какой толк от этой информации тем, кто находится выше начальника отдела, из которого эти ресурсы берутся. Начальнику подразделения это нужно знать. Но, как по мне, выше должна быть только информация о том, что возможность решить задачу есть и о сроках, в которые это будет сделано. Как уже начальник подразделения будет обеспечивать выполнение взятых на себя обязательств -- это уже не важно (та самя инкапсуляция).