Вы удивитесь - но вопрос только в сложности проекта. Там где типовой линейный персонал пятерочки испытывает затруднения с тем, чтобы правильно расставить товар (например, из-за банального незнания языка и неумения прочитать этикетку) - грамотный инженер все сделает сам и в лучшем виде. Но начните увеличивать сложность и степень неопределенности в проекте - и внезапно даже лучшие команды инженеров начнут ошибаться и производить время от времени лажу...
Добро пожаловать в реальный мир управления людьми и проектами. Вы же их не коллективом под конкретную задачу нанимали ? И когда задачу ставили - нет возможности каждому под череп заглянуть и увидеть какие и как у него там шестеренки закрутились. В результате - вполне реально, когда в большом проекте совершенно квалифицированные, инициативные (и много еще положительных прилагательных) люди делают куски системы так, что они никогда друг с другом не состыкуются. Еще раз - не потому что они идиоты или вредители, а просто потому что у каждой сложной задачи существует множество технических решений (каждое из которых - по сути некий компромисс между достижимыми характеристиками). И по-умолчанию, в большом коллективе у вас нет гарантии что все со всеми синихронизированы. Опять же - почему бы вам не начать читать ? Например, как был потерян марсианский зонд из-за того что часть команды считала в единицах СИ, а другая - в имперских. И это не потому что там идиоты "кто их таких нанял!?" сидели - что NASA, что Ливерморская лаборатория - и до того, и после, сделали немало волшебной сложности проектов...
Обеспечить в нужном объеме обмен информацией и синхронизацию - одна из задач проектного управления.
Вы заблуждаетесь в том смысле, что описанный вами процесс ("не зная броду не суйся в воду", "знать характеристики объекта управления", и т.д.) - не является единственно возможным (и более того, в реальности встречается не слишком часто).
Начать с того, что объект управления (коллектив человеков) устроен сильно сложнее, скажем, нихромовой проволоки-нагревателя - и поэтому вы устанете описываеть его характеристики с точки зрения ТАУ. А даже если опишете - это будет такое нагромождение дифур, что вы второй раз устанете его применять для управления. И все-равно скатитесь в эмпирические методы...
Второе - почитайте мемуары каких-нибудь грамотных советских руководителей. Если любите космос, то, например, Мишина и Чертока... Вот поставили вам задачу - первым в мире обеспечить мягкую посадку на луну, и из какого колодезя мудрости вы собираетесь черпать недостающие знания ?! И да, луна - пример утрированный во всех смыслах (опять же, почитайте - сколько раз пускали пока не сделали, и в какие деньги это обошлось!). Но в любом сколько-то сложном проекте (в программировании так уж точно!) - есть элемент неопределенности и неизвестности. Собственно, если бы его не было - обычно можно не начинать проект, а прямо взять и купить что-то готовое.
Последнее: ваши аргументы типа "...мошенники начинают чувствовать" и проч - отдают паранойей. Если вы в состоянии вернуть обсуждение вопроса к сухому академическому формату с опорой на факты и без эмоций - я был бы признателен...
Вы исходите из того, что где-то в идеальном мире уже "все подумано за нас", существует некое "понимание", и надо только доносить до подчиненных их задачи... Жизнь сложнее - иногда встречается задача, которую никто пока точно не знает как делать. А делать надо... И вот тут и начинается искусство управления - выстраивание коммуникаций, обратных связей и так далее.
За скобками отмечу, что ваши мысли трудно понять. Если вы в состоянии излагать их более последовательно - я был бы признателен...
В сложном проекте - внезапно оказывается, что все эти образованные, целеустремленные, амбициозные и квалифицированные по-отдельности люди, собравшись вместе - творят какую-то лютую дичь! Я понимаю организацию и контроль не в смысле дрессировки (чтобы в столовую строем ходить) - а реальное согласование планов работ и контроль их выполнения. Чтобы в конце - концов, машина поехала, самолет взлетел, учетная система обновилась, и так далее...
За годы работы - я обратил внимание на соотношение условно-постоянных и переменных затрат руководителя (времени, ресурсов, усилий, и т.д.). В состоянии, когда у человека нет подчиненных, и он делает некую работу сам - затраты на коммуникацию и контроль почти нулевые: самому с собой в голове договориться и быстро, и легко. Как только у нас полявляется хотя бы один подчиненный, скачком возникают немалые расходы на коммуникацию (потому что в мыслях теперь нельзя - надо переходить на голос/письмо - а там пропускная способность канала на порядки ниже). Бывает конечно, что вам везет и вы срываете банк - можете в целом обрисовать задачу, и потом только прийти за результатом. Но это уже не сколько подчиненный, сколько партнер в малом бизнесе получается. Если же вы идете по классике менеджмента - то добро пожаловать в организацию скрам-ритуалов (или любых других процедур регулярного контроля и обмена информацией). И я имею утверждать, что в среднем случае - от одного подчиненного легче не становится. Теперь добавляем еще одного подчиненного - и удивительным образом оказывается, что переменные расходы на добавление еще одного человека в коммуникацию - очень малы. Да, они есть - но по сравнению с первым сотрудником, они почти незаметны. Ибо дейлик как был 5 минут, так и остался. Ибо груминг как был час, так и остался... А работы они делают уже в два раза больше - и это заметное облегчение. И это продолжается до тех пор, пока не превышена норма управления (5-7 человек в группе). После этого надо вводить дополнительный уровень иерархии - и это опять головная боль, сравнимая с наймом первого сотрудника.
В итоге - моя личная рекомендация, не претендующая на универсальность: начинаете сами, терпите пока не будет ресурсов нанять двух сотрудников - и играете сразу с двух. Потом по мере необходимости добираете, и когда их станет 7-8 - делите на две группы (руководитель + 2 подчиненных, или руководитель + 3 подчиненных), и теперь руководите уже двумя старшими групп. В общем, так чтобы нигде не получалось что у руководителя ровно один подчиненный - это очень неэффективно (пока не появится телепатия или передача информации из мозга в мозг через высокоскоростные импланты).
Добавлю, что в большинстве случаев, следует избегать ситуации, когда у вас ровно один подчиненный. То, что он вам будет помогать - это только кажется. Сколько он вам сэкономит работой, столько заберет обратно коммуникацией и контролем. Плюс, люди имеют свойство болеть, ходить в отпуск, увольняться - и далее по тексту. Чтобы страховать функционал - вам придется постоянно быть в курсе деталей чтобы подхватить выпавшую работу (а потом - вернуть обратно!). Поэтому терпите, скрежещите зубами - но начинайте нанимать людей только тогда, когда работой можно занять сразу двоих.
Я понял вашу стратегию: от задач вы получаете стори-поинты, из истории вы берете velocity команды, делите одно на другое - получаете дни. При этом, неявное допущение заключается в том, что существует корреляция между увеличением количества стори-поинтов и временем, которое команда затратит на их сжигание (иначе бы вы одно на другое не делили бы). Собственно, весь хоровод был затеян только для того, чтобы не вносить систематическую ошибку, оценивая сразу в человеко-днях (ибо работа всегда занимает все отведенное для нее время...). Введя промежуточную единицу оценки, мы надеемся что через исторические данные мы устраним систематическую погрешность, и получим хорошие и правильные человеко-дни на выходе.
В результате проверки на данных, которые были собраны на проекте, оказалось что корреляция между стори-поинтами и реальными сроками практически отсутствует. Если мы смотрим на картинку, где по одной координате отражается число стори-поинтов, а с другой - реальное число дней которое делалась задача - получается плоское распределение (бывает что задачу на 10 поинтов удается сжечь за день, а бывает что над задачей из 3 поинтов сидят неделю). После нескольких обсуждений на ретро, стало понятно что задачи не типовые, и оценки даются "по ощущениям". А пока ты задачу делать не начал, ощущения - довольно ненадежная штука...
По итогу, как я и написал - в команде стори-поинты отменены. Если попадается задача, которую мы раньше уже делали (или делали похожую) - тогда мы можем сразу дать оценку в днях или человеко-днях. Если же такого опыта нет - то увы, можем только гарантировать что будем нарезать на мелкие подзадачи в процессе чтобы был понятен прогресс.
Мы в какой-то момент посмотрели корреляцию между story-points и тем, сколько задача шла от входа до выхода - и не увидели корреляции (ну, почти). Поэтому, волевым решением оценку задач со всеми ритуалами отменили. Оставили пожелание нарезать подзадачи не больше чем на 1-3 дня (сабтаски создает сам разработчик). Поскольку статусы задач все-равно обсуждаются в дейли, и есть алерты на зависание задач без движения - хуже точно не стало. А пожалуй что и лучше: можно лишний час работать, а не играть в покер с числами фибоначчи...
Я не понимаю логику HR. То есть, они понимают что ушедший (и пришедший) сотрудник стоят денег. Они понимают, что есть оплата за найм. Но при этом любым средствами не хотят сделать так, чтобы "новый специалист обошелся ДЕШЕВЛЕ ушедшего". Ну потому что новый специалист еще не знает специфику, и ему платить больше, чем сотруднику который уже себя показал - глупо. Но нет - экономия на зарплате - это святое для российского бизнеса. Он настолько развращен ситуацией из 90-х и 2000-х (когда специалистов было стабильно больше чем приличных рабочих мест), что даже сейчас говорит правильные слова, но категорически не готов действовать в соответствии со сказанным...
А почему тогда все разработчики сред для этих самых "языков стандарта МЭК" делают кастомный блок, где можно записать текстом кусок программы ? И почему за исключением элементарных проектов (например, где жесткую релейную логику меняют на МК) - этими блоками активно пользуются ? И уж тогда совсем непонятно, почему нельзя просто всю программу сделать текстом, чтобы не тыкать мышкой в эти блоки и в них проваливаться ?
Мне, например, за это гораздо больше нравились контроллеры серии I7xxx и pds-7xx от ICP-DAS. Не извращаешься с непонятными визуальными изысками, а вот тебе библиотека, и пиши на Borland C++ 3.1 как в славные 90-е годы на i386. :-) Мы себе забабахали как-бы эмулятор этой среды в Linux и всю логическую отладку с юнит-тестами и прочими плюшками делали там. А потом уже компилировали под железо. После полноценных CI-CD пайпланов и нормальной среды разработки - обратно ползти под Codesys - пытка...
Давайте так - задача разработчика даже шире чем построение модели. Задача разработчика - это описание некоторого варианта будущего (реализуемого в рамках возможностей вычислительной системы), причем описание полное и непротиворечивое.
Соответственно, чтобы описать желаемое будущее, неплохо хотя бы для себя понимать - чего же мы хотим. И это - первое чему надо учиться разработчику (вообще-то говоря, всем людям следует этому учиться, но в большом количестве профессий вы можете иметь кашу в голове, и при этом сносно выполнять повседневные обязанности - но не в разработке!).
Дальше - после того как у вас в голове есть вполне определенная картина будущего, необходимо ее полно и непротиворечиво описать (а при обнаружении неоднозначности или неполноты - скорректировать). Вот тут в дело вступают языки программирования. Потому что естественный язык позволяет легко совершить ошибку, так как его средства слишком выразительны. Язык программирования на порядки беднее естественного языка, и требует местами знатно извратиться чтобы выразить довольно простые концепции (такие как "одновременность"). Однако, бонусом вы получаете встроенную в язык однозначность, защищающую вас от свойственных естественным языкам расплывчатых и неоднозначных описаний.
Поэтому - во-первых, надо уметь мыслить полно и непротиворечиво, а только во-вторых учить специальный язык программирования. Знание только языка программирования - ничего не дает. Работая со студентами, я регулярно видел людей, которые профессионально непригодны к программированию. Не потому что они не могут выучить Java или C++ - а потому что им нечего сказать на этом языке. Ну не родит голова достойные мысли, что с этим поделаешь ?!
В этом смысле, я скептически отношусь к проектам типа визуальных сред программирования, поскольку они пытаются понизить порог входа не там, где он на самом деле есть. Понятно что программирование на ассемблере или в машинных кодах - это проблема. Но с изобретением фортрана и сонма других языков высокого уровня, этой проблемы больше нет. Снижая порог еще дальше - вы получите больше людей, которые задумчиво таскают мышкой по экрану управляющие блоки в надежде что случайно получится что-то дельное (годится для младших детей, познающих мир в формате экспериментов - но не годится для взрослых). Кроме того, картинки-пиктограммы всегда будут иметь более низкую информационную емкость, и сколько-то сложная программа (с которой еще можно как-то работать в текстовом виде) - в визуальной среде будет просто необозрима.
Помогает ли изучение моделирования программировать ? Да - ровной в той же степени как изучение высшей математики или физики. Это сложная деятельность, которая требует определенной дисциплины мышления (и вообще умения думать). Если вы освоили это, то и программирование для вас не будет большой проблемой - всего лишь еще один язык на который надо перенести свои мысли.
Анекдот напоследок. Студент в СССР сдает историю КПСС, и делает это откровенно плохо. "Вы совершенно не думаете над своими ответами!" - укоряет его преподаватель. "Так Ленин же запретил!" - радостно заявляет студент. Преподаватель: "*#@&^#@ ??!". Студент: полное собрание сочинений, том такой-то, страница такая-то, абзац, последнее предложение на странице. Преподаватель достает с полки и открывает том сочинений вождя: "Было бы ошибкой думать...". (C) В.И.Ленин
Не скажите. Имел я поддерживать в начале двухтысячных неплохую систему товародвижения Gestori от условно франко-московских товарищей из компании Франс Информатик Текноложи. Там было уже в тот момент >300 конфигурационных параметров. И нас явным образом предупредили, что НИКТО не знает что случится если мы начнем произвольным образом их переключать. Программисты тестировали и отлаживали определенную комбинацию - после чего она ставилась на поддержку. То есть с достаточно развитой системой конфигурационных параметров - наличие программистов помимо аналитиков - становится обязательным. Можно спорить и исследовать, где проходит эта граница - но ее объективное существование у меня сомнений не вызывает. :-)
Напомню что и 1С рекламировалась когда-то в противовес бухгалтерским системам на Foxpro, Clipper и Clarion на утверждении что (наконец-то!!!) не надо будет держать программистов при бухгатерии, а формулы и правила расчетов бухгалтер сможет поменять сам на языке "похожем на обычный русский". Первая часть - вытеснение конкурентов - прошла успешно. Вторая - как-то не очень. Я бы даже сказал, что бухгалтер без поддержки программистов сейчас еще беспомощнее чем в начале 2000-х. Тогда все-таки и формы учета были попроще, и правила налогового учета во многом совпадали с бухгалтерским - так что всегда был бэкап-план в виде журнально-ордерной системы учета...
Скажем прямо - что было до того, в регионах воспринималось как очередной (но вполне рядовой) бзик в отношениях между руководителями РФ и Украины. Они и до того непрерывно что-то делили - то газ, то флот, то землю между русскими/украинцами/татарами... Нам за 3000+ километров плохо было видно.
На самом деле, конечно, с позиции сегодняшнего дня - видно что спусковым крючком была обратная рокировочка в стиле: "Давай пока твоим мужем Володя побудет, а потом опять я", разгон протестов и поездка императора ПуИ в Кремль по пустым улицам. Экономика без политических свобод уже почти не росла, технократические решения типа повышения пенсионного возраста давили на популярность - и в голове царя зашептал голос: "Нам нужна маленькая победоносная война...". Тем более, что временщик Дима имел в активе формальную победу в такой войне 2008 года (и хотя все пока славили великого кормчего как архитектора этой победы отводя Диме только техническую роль - кто его знает как может это повернуться со временем ? Нет - надо обязательно чтобы была своя...).
Кстати, я считаю что и ко второй войне 2022 года спусковым крючком были события в Беларуси и откровенно травоядная позиция Европы и США. Царь убедился (а придворные - радостно подтвердили) что запад как никогда слаб, и достаточно чуть-чуть надавить чтобы смазанная победа 2014 года (вкупе с хозяйственными проблемами типа крымского канала) превратилась в полную и окончательную. Оно, понимаешь ли, хотело лежать в мавзолее на правах исправителя ошибок советских генсеков и быть в учебниках истории чем-то средним между Наполеоном и Екатериной нашей второй... :-(
В регионах, опять же, одобрения никого не спрашивал - поставили перед фактом. Абсурдно думать, что условные омичи рады что за счет их нищего бюжета чинят дороги и свет в условном стаханове...
Парадокс конфигурации Тьюринга. Чтобы избавиться от программистов, кастомные решения написанные на языке программирования высокого уровня - заменяются на коробочные. Любое коробочное решение требует конфигурации, чтобы быть применимым для максимального круга клиентов. Конфигурация со временем непрерывно усложняется, пока не станет равномощна вычислительной машине Тьюринга. С этого момента, конфигурация становится высокоспециализированным языком программирования (или вычислительной системой) с отвратительным обеспечением инструментами, без нормальной отладки и с очень узким коммьюнити. Чтобы разобраться как настроить систему используя средства тьюринговой конфигурации, приходится нанимать специалиста по программированию... Круг замыкается.
У меня другие данные. Первый удар был в 2014 году, как сбили нидерладнский Боинг и скакнул курс доллара. До этого, разница в зарплатах разработчика на внутреннем и зарубежном рынке была процентов, ну... тридцать. И на аутсорс надо было знать английский, а на внутренний - нет. А тут зарплаты стали различаться этак раза в два, два с половиной... Второй удар - это когда окологосударственные корпорации решили уйти от традиционной модели "вендор-заказчик" и решили втянуть в себя ит, создав центры разработки типа Сбертеха. Норма прибыли госбанка настолько выше нормы прибыли любого реального бизнеса в регионах - что уже в этот момент специалисты на производственных предприятиях тупо начали заканчиваться - и началась зарплатная гонка. Ковид - это, я бы сказал, уже самый конец истории... Да, понятно, что удаленка немного ускорила эти процессы позволяя наняться из глубинки на московскую позицию. Однако, не надо обольщаться - московские деньги в регионе радуют только временно. Потом внезапно выясняется, что когда у тебя зимой не чистят толком снег кроме как в центре, весной стоит вода с говнами по колено на улицах, парк вырубили под торговый центр друга губернатора, в местной поликлинике почти нет врачей-специалистов, общественный транспорт разрушен, а дороги каждый год выглядят так как будто их бомбили фашисты с хенкеля - зарплата уже не радует. И это еще не пошли дети в школу (поставьте новые окна, купите краску для доски, сбросьтесь на ремонт крыши и далее по тексту - причем, учителя тоже деградируют и вы учите детей сами дома)... Дальше специалист смотрит, вздыхает, и едет в МСК. СПб или на худой конец на юг. А оттуда в Европу или Штаты. Исчерпание человеческого капитала...
Более того, я сам из яростного патриота родного региона в какой-то момент превратился в пессимиста и циника. А всего-то я сделал прикидочный расчет - во сколько обойдется всех сибирских разработчиков перевезти в МСК или СПБ (метрополию), в сравнении с ежегодными затратами на инфраструктуру чтобы оставить их со сравнимым качеством жизни в Сибири...
Бессмысленно обвинять в этом удаленку или какое-то еще разовое событие. То что вы описываете - "ни программистов, ни аналитиков она не может найти от слова совсем..." - это уже самый финал процесса, который называется "исчерпание человеческого капитала". Мы прошли длинной дорогой... В 90-е годы на улицу было выброшего гигантское количество инженеров из ВПК (и - всегда привожу эту историю: на фоне многомесячных неплатежей зарплаты в оборонке сибирского миллионника, банки спокойно искали, и находили! - уборщиц (!!!) с высшим образованием). В сочетании с феодально-колониальной моделью развития страны (Москва и отчасти Питер - метрополия, остальное - внутренние колонии с местными царьками и/или назначенными губернаторами) - это гарантировало отсутствие ресурсов для развития на периферии страны. В результате, регионы выживали ровно тем чем написано - проедая советские основные средства в первые годы, и человеческий капитал во все последующие. Ученые делали доклады об этом все нулевые годы, и все десятые. Кого это волновало ? Никого: проблемы негров шерифа не волнуют... Если бизнесы в регионах только сейчас осознали что они не выживут - это только их недальновидность. Впрочем, многие вполне себе подозревали это и раньше: поэтому выжимали из регионального бизнеса все соки, и тащили деньги в офшор. Чем, конечно, еще сильнее подрывали воспроизводство человеческого капитала. В сухом итоге - регионы РФ будут деградировать и подыхать еще быстрее чем раньше. Жить будут только те, кому денег подкидывает федеральный центр (в зависимости от коньюнктуры). Более того, деградация и обезлюдивание регионов воспринимается федеральным центром положительно, так как чисто по бухгалтерии это позволяет сократить дотации. Потом это либо придется реколонизировать еще раз при нормальной власти, либо это успеют сделать соседи, и РФ станет сильно меньше по площади, чем мы привыкли видеть на картах. Волнует ли это правящие элиты ? Конечно же нет. Их интересуют только те регионы в которых можно добывать природные ресурсы на экспорт, и население которое требуется для обслуживания этой деятельности (а в идеале - трудовые мигранты вахтовым методом). Я не идеализирую советскую власть, но она ставила задачу обживать регионы за Уралом. Нынешняя власть такой задачи не имеет...
Принтер, практически как любой другой станок - не имеет смысла сам по себе. Он приобретает ценность только тогда, когда встроен в конкретную производственную цепочку. Смотрите: основное достоинство принтера это быстрое изготовление прототипа или оснастки. Если мне "вотпрямщас" понадобился шаблон для сверления с расстоянием до края 11.3мм - я его за 10 минут напечатаю на принтере и тут же пущу в работу. Как только мы включаем в эту цепочку стороннего поставщика - 10 минут превращаются в пол рабочего дня (и это в лучшем случае). В результате, ухудшение составляет 240:10 = 24 раза... Таким образом, для разовых заказов, сторонний принтер - ну такое себе!
Второе преимущество принтера - это низкие постоянные расходы (и соответственно, минимальная партия - "...от одной детали"). Нужно встраиваться в цепочки ремонта, которые требуют не слишком большой ассортимент деталей, и не слишком много - но регулярно. Клипсы какие-нибудь для автосервисов, не знаю что еще. После того как вы с ними отработали модель - они могут вам просто регулярно присылать заказ - чего и сколько, а вы будете печатать малую серию и отдавать.
Пожалуй, самое правильное что делают коллеги из статьи - это продажа сопутствующих услуг. Не надо продавать услуги печати, надо продавать решение проблемы. И в этом случае, ценник можно и еще задирать. Пока ваши услуги стоят дешевле чем простой оборудования пока запчасть идет из Китая (ну или из Москвы в регион) - заказчик будет платить и плакать от счастья.
Расскажу байку для закрепления пройденного. Если итальянец пошел покупать корову - значит он собрался делать и продавать сыр. Если российский крестьянин пошел покупать корову - он собрался сдавать молоко на завод по 3 рубля 20 копеек за килограмм (и каждый год подавать на конкурс чтобы ему на поддержание штанов дали субсидию от местного минсельхоза). Вот держать парк принтеров и печатать разовые заказы на авито - это сдача молока на молзавод, как ни прискорбно: всю добавленную стоимость забирает кто-то другой. Находите хорошие цепочки, и расширяйтесь вертикально - выдавливая конкурентов и занимая их место. Уже тот факт, что они приходят к вам за печатью и конструкторским ресурсом уже говорит об их интеллектуальной ограниченности. Так и какого черта?!
Нет, дело не в том, что дженералисты знают "всё ит". Эта эпоха кончилась, наверное, в 70-х. Дело в том, что они знают, как оно там работает под слоями абстракций и геологическими формациями библиотек. Потому что еще успели поработать на относительно медленных и проще устроенных системах ближе к железу. А разговаривая с относительно недавними разработчиками - я иногда не понимаю, как они вообще ухитряются выдавать годное. Ибо их базовые знания - либо чистая мифология и зельеварение (известно, что если хочешь полететь на метле - надо взять сушеную жабу, слизь саламандры, глаза жужелицы и варить на медленном огне 6 часов), либо сознательная слепота ("там тьма, ужас и монстры - я об этом даже не буду думать"). Мне это дико (благо я начинал с восьмибитных КР580ВМ80А, цельнотянутых i8080, и далее через все поколения персоналок и кусок промышленных контроллеров) - я бы повесился работать с системой, которая с определенного уровня становится магией, и с которой ты при всем желании ничего не можешь сделать. А молодым ничего, норм...
Впрочем, я сейчас еще одну интересную вещь скажу. Наблюдая за своими детьми, я обнаружил что они вообще к компьютеру относятся совершенно не так как я. Для них ПК - это бытовой прибор наравне с микроволновкой или чайником. Хотим разогреть пиццу - идем к микроволновке. Хотим в интернет или поиграть - включаем компьютер. А для меня, компьютер всегда был потрясающим приключением, которое хочется программировать. Впрочем, когда я поделился этим со своими родителями - они сказали, что история повторяется. Для них в институте - один калькулятор (Б3-18) в группе был подарком судьбы: вместо расчетов столбиком, логарифмической линейки и таблиц Брадиса - просто жмешь кнопки, и получаешь сразу ответ (втч логарифмичекие функции, экспонента, тригонометрические и обратные!). И они (если он попадал в руки) на нем считали, даже если не было особо и нужно! :-) А мы (их дети) уже относились к калькуляторам безо всякого пиетета, и без понимания что оно там внутри делает.
Да ну! Уж если народ на это шел - то обычно программировался контроллер дисковода через порты ввода-вывода... Кто ж серьезную защиту через bios будет делать...
Вы удивитесь - но вопрос только в сложности проекта. Там где типовой линейный персонал пятерочки испытывает затруднения с тем, чтобы правильно расставить товар (например, из-за банального незнания языка и неумения прочитать этикетку) - грамотный инженер все сделает сам и в лучшем виде. Но начните увеличивать сложность и степень неопределенности в проекте - и внезапно даже лучшие команды инженеров начнут ошибаться и производить время от времени лажу...
Добро пожаловать в реальный мир управления людьми и проектами. Вы же их не коллективом под конкретную задачу нанимали ? И когда задачу ставили - нет возможности каждому под череп заглянуть и увидеть какие и как у него там шестеренки закрутились. В результате - вполне реально, когда в большом проекте совершенно квалифицированные, инициативные (и много еще положительных прилагательных) люди делают куски системы так, что они никогда друг с другом не состыкуются. Еще раз - не потому что они идиоты или вредители, а просто потому что у каждой сложной задачи существует множество технических решений (каждое из которых - по сути некий компромисс между достижимыми характеристиками). И по-умолчанию, в большом коллективе у вас нет гарантии что все со всеми синихронизированы. Опять же - почему бы вам не начать читать ? Например, как был потерян марсианский зонд из-за того что часть команды считала в единицах СИ, а другая - в имперских. И это не потому что там идиоты "кто их таких нанял!?" сидели - что NASA, что Ливерморская лаборатория - и до того, и после, сделали немало волшебной сложности проектов...
Обеспечить в нужном объеме обмен информацией и синхронизацию - одна из задач проектного управления.
Вы заблуждаетесь в том смысле, что описанный вами процесс ("не зная броду не суйся в воду", "знать характеристики объекта управления", и т.д.) - не является единственно возможным (и более того, в реальности встречается не слишком часто).
Начать с того, что объект управления (коллектив человеков) устроен сильно сложнее, скажем, нихромовой проволоки-нагревателя - и поэтому вы устанете описываеть его характеристики с точки зрения ТАУ. А даже если опишете - это будет такое нагромождение дифур, что вы второй раз устанете его применять для управления. И все-равно скатитесь в эмпирические методы...
Второе - почитайте мемуары каких-нибудь грамотных советских руководителей. Если любите космос, то, например, Мишина и Чертока... Вот поставили вам задачу - первым в мире обеспечить мягкую посадку на луну, и из какого колодезя мудрости вы собираетесь черпать недостающие знания ?! И да, луна - пример утрированный во всех смыслах (опять же, почитайте - сколько раз пускали пока не сделали, и в какие деньги это обошлось!). Но в любом сколько-то сложном проекте (в программировании так уж точно!) - есть элемент неопределенности и неизвестности. Собственно, если бы его не было - обычно можно не начинать проект, а прямо взять и купить что-то готовое.
Последнее: ваши аргументы типа "...мошенники начинают чувствовать" и проч - отдают паранойей. Если вы в состоянии вернуть обсуждение вопроса к сухому академическому формату с опорой на факты и без эмоций - я был бы признателен...
Вы исходите из того, что где-то в идеальном мире уже "все подумано за нас", существует некое "понимание", и надо только доносить до подчиненных их задачи... Жизнь сложнее - иногда встречается задача, которую никто пока точно не знает как делать. А делать надо... И вот тут и начинается искусство управления - выстраивание коммуникаций, обратных связей и так далее.
За скобками отмечу, что ваши мысли трудно понять. Если вы в состоянии излагать их более последовательно - я был бы признателен...
В сложном проекте - внезапно оказывается, что все эти образованные, целеустремленные, амбициозные и квалифицированные по-отдельности люди, собравшись вместе - творят какую-то лютую дичь! Я понимаю организацию и контроль не в смысле дрессировки (чтобы в столовую строем ходить) - а реальное согласование планов работ и контроль их выполнения. Чтобы в конце - концов, машина поехала, самолет взлетел, учетная система обновилась, и так далее...
За годы работы - я обратил внимание на соотношение условно-постоянных и переменных затрат руководителя (времени, ресурсов, усилий, и т.д.). В состоянии, когда у человека нет подчиненных, и он делает некую работу сам - затраты на коммуникацию и контроль почти нулевые: самому с собой в голове договориться и быстро, и легко. Как только у нас полявляется хотя бы один подчиненный, скачком возникают немалые расходы на коммуникацию (потому что в мыслях теперь нельзя - надо переходить на голос/письмо - а там пропускная способность канала на порядки ниже). Бывает конечно, что вам везет и вы срываете банк - можете в целом обрисовать задачу, и потом только прийти за результатом. Но это уже не сколько подчиненный, сколько партнер в малом бизнесе получается. Если же вы идете по классике менеджмента - то добро пожаловать в организацию скрам-ритуалов (или любых других процедур регулярного контроля и обмена информацией). И я имею утверждать, что в среднем случае - от одного подчиненного легче не становится. Теперь добавляем еще одного подчиненного - и удивительным образом оказывается, что переменные расходы на добавление еще одного человека в коммуникацию - очень малы. Да, они есть - но по сравнению с первым сотрудником, они почти незаметны. Ибо дейлик как был 5 минут, так и остался. Ибо груминг как был час, так и остался... А работы они делают уже в два раза больше - и это заметное облегчение. И это продолжается до тех пор, пока не превышена норма управления (5-7 человек в группе). После этого надо вводить дополнительный уровень иерархии - и это опять головная боль, сравнимая с наймом первого сотрудника.
В итоге - моя личная рекомендация, не претендующая на универсальность: начинаете сами, терпите пока не будет ресурсов нанять двух сотрудников - и играете сразу с двух. Потом по мере необходимости добираете, и когда их станет 7-8 - делите на две группы (руководитель + 2 подчиненных, или руководитель + 3 подчиненных), и теперь руководите уже двумя старшими групп. В общем, так чтобы нигде не получалось что у руководителя ровно один подчиненный - это очень неэффективно (пока не появится телепатия или передача информации из мозга в мозг через высокоскоростные импланты).
Добавлю, что в большинстве случаев, следует избегать ситуации, когда у вас ровно один подчиненный. То, что он вам будет помогать - это только кажется. Сколько он вам сэкономит работой, столько заберет обратно коммуникацией и контролем. Плюс, люди имеют свойство болеть, ходить в отпуск, увольняться - и далее по тексту. Чтобы страховать функционал - вам придется постоянно быть в курсе деталей чтобы подхватить выпавшую работу (а потом - вернуть обратно!). Поэтому терпите, скрежещите зубами - но начинайте нанимать людей только тогда, когда работой можно занять сразу двоих.
Я понял вашу стратегию: от задач вы получаете стори-поинты, из истории вы берете velocity команды, делите одно на другое - получаете дни. При этом, неявное допущение заключается в том, что существует корреляция между увеличением количества стори-поинтов и временем, которое команда затратит на их сжигание (иначе бы вы одно на другое не делили бы). Собственно, весь хоровод был затеян только для того, чтобы не вносить систематическую ошибку, оценивая сразу в человеко-днях (ибо работа всегда занимает все отведенное для нее время...). Введя промежуточную единицу оценки, мы надеемся что через исторические данные мы устраним систематическую погрешность, и получим хорошие и правильные человеко-дни на выходе.
В результате проверки на данных, которые были собраны на проекте, оказалось что корреляция между стори-поинтами и реальными сроками практически отсутствует. Если мы смотрим на картинку, где по одной координате отражается число стори-поинтов, а с другой - реальное число дней которое делалась задача - получается плоское распределение (бывает что задачу на 10 поинтов удается сжечь за день, а бывает что над задачей из 3 поинтов сидят неделю). После нескольких обсуждений на ретро, стало понятно что задачи не типовые, и оценки даются "по ощущениям". А пока ты задачу делать не начал, ощущения - довольно ненадежная штука...
По итогу, как я и написал - в команде стори-поинты отменены. Если попадается задача, которую мы раньше уже делали (или делали похожую) - тогда мы можем сразу дать оценку в днях или человеко-днях. Если же такого опыта нет - то увы, можем только гарантировать что будем нарезать на мелкие подзадачи в процессе чтобы был понятен прогресс.
Мы в какой-то момент посмотрели корреляцию между story-points и тем, сколько задача шла от входа до выхода - и не увидели корреляции (ну, почти). Поэтому, волевым решением оценку задач со всеми ритуалами отменили. Оставили пожелание нарезать подзадачи не больше чем на 1-3 дня (сабтаски создает сам разработчик). Поскольку статусы задач все-равно обсуждаются в дейли, и есть алерты на зависание задач без движения - хуже точно не стало. А пожалуй что и лучше: можно лишний час работать, а не играть в покер с числами фибоначчи...
Я не понимаю логику HR. То есть, они понимают что ушедший (и пришедший) сотрудник стоят денег. Они понимают, что есть оплата за найм. Но при этом любым средствами не хотят сделать так, чтобы "новый специалист обошелся ДЕШЕВЛЕ ушедшего". Ну потому что новый специалист еще не знает специфику, и ему платить больше, чем сотруднику который уже себя показал - глупо. Но нет - экономия на зарплате - это святое для российского бизнеса. Он настолько развращен ситуацией из 90-х и 2000-х (когда специалистов было стабильно больше чем приличных рабочих мест), что даже сейчас говорит правильные слова, но категорически не готов действовать в соответствии со сказанным...
А почему тогда все разработчики сред для этих самых "языков стандарта МЭК" делают кастомный блок, где можно записать текстом кусок программы ? И почему за исключением элементарных проектов (например, где жесткую релейную логику меняют на МК) - этими блоками активно пользуются ? И уж тогда совсем непонятно, почему нельзя просто всю программу сделать текстом, чтобы не тыкать мышкой в эти блоки и в них проваливаться ?
Мне, например, за это гораздо больше нравились контроллеры серии I7xxx и pds-7xx от ICP-DAS. Не извращаешься с непонятными визуальными изысками, а вот тебе библиотека, и пиши на Borland C++ 3.1 как в славные 90-е годы на i386. :-) Мы себе забабахали как-бы эмулятор этой среды в Linux и всю логическую отладку с юнит-тестами и прочими плюшками делали там. А потом уже компилировали под железо. После полноценных CI-CD пайпланов и нормальной среды разработки - обратно ползти под Codesys - пытка...
Давайте так - задача разработчика даже шире чем построение модели. Задача разработчика - это описание некоторого варианта будущего (реализуемого в рамках возможностей вычислительной системы), причем описание полное и непротиворечивое.
Соответственно, чтобы описать желаемое будущее, неплохо хотя бы для себя понимать - чего же мы хотим. И это - первое чему надо учиться разработчику (вообще-то говоря, всем людям следует этому учиться, но в большом количестве профессий вы можете иметь кашу в голове, и при этом сносно выполнять повседневные обязанности - но не в разработке!).
Дальше - после того как у вас в голове есть вполне определенная картина будущего, необходимо ее полно и непротиворечиво описать (а при обнаружении неоднозначности или неполноты - скорректировать). Вот тут в дело вступают языки программирования. Потому что естественный язык позволяет легко совершить ошибку, так как его средства слишком выразительны. Язык программирования на порядки беднее естественного языка, и требует местами знатно извратиться чтобы выразить довольно простые концепции (такие как "одновременность"). Однако, бонусом вы получаете встроенную в язык однозначность, защищающую вас от свойственных естественным языкам расплывчатых и неоднозначных описаний.
Поэтому - во-первых, надо уметь мыслить полно и непротиворечиво, а только во-вторых учить специальный язык программирования. Знание только языка программирования - ничего не дает. Работая со студентами, я регулярно видел людей, которые профессионально непригодны к программированию. Не потому что они не могут выучить Java или C++ - а потому что им нечего сказать на этом языке. Ну не родит голова достойные мысли, что с этим поделаешь ?!
В этом смысле, я скептически отношусь к проектам типа визуальных сред программирования, поскольку они пытаются понизить порог входа не там, где он на самом деле есть. Понятно что программирование на ассемблере или в машинных кодах - это проблема. Но с изобретением фортрана и сонма других языков высокого уровня, этой проблемы больше нет. Снижая порог еще дальше - вы получите больше людей, которые задумчиво таскают мышкой по экрану управляющие блоки в надежде что случайно получится что-то дельное (годится для младших детей, познающих мир в формате экспериментов - но не годится для взрослых). Кроме того, картинки-пиктограммы всегда будут иметь более низкую информационную емкость, и сколько-то сложная программа (с которой еще можно как-то работать в текстовом виде) - в визуальной среде будет просто необозрима.
Помогает ли изучение моделирования программировать ? Да - ровной в той же степени как изучение высшей математики или физики. Это сложная деятельность, которая требует определенной дисциплины мышления (и вообще умения думать). Если вы освоили это, то и программирование для вас не будет большой проблемой - всего лишь еще один язык на который надо перенести свои мысли.
Анекдот напоследок. Студент в СССР сдает историю КПСС, и делает это откровенно плохо. "Вы совершенно не думаете над своими ответами!" - укоряет его преподаватель. "Так Ленин же запретил!" - радостно заявляет студент. Преподаватель: "*#@&^#@ ??!". Студент: полное собрание сочинений, том такой-то, страница такая-то, абзац, последнее предложение на странице. Преподаватель достает с полки и открывает том сочинений вождя: "Было бы ошибкой думать...". (C) В.И.Ленин
Не скажите. Имел я поддерживать в начале двухтысячных неплохую систему товародвижения Gestori от условно франко-московских товарищей из компании Франс Информатик Текноложи. Там было уже в тот момент >300 конфигурационных параметров. И нас явным образом предупредили, что НИКТО не знает что случится если мы начнем произвольным образом их переключать. Программисты тестировали и отлаживали определенную комбинацию - после чего она ставилась на поддержку. То есть с достаточно развитой системой конфигурационных параметров - наличие программистов помимо аналитиков - становится обязательным. Можно спорить и исследовать, где проходит эта граница - но ее объективное существование у меня сомнений не вызывает. :-)
Напомню что и 1С рекламировалась когда-то в противовес бухгалтерским системам на Foxpro, Clipper и Clarion на утверждении что (наконец-то!!!) не надо будет держать программистов при бухгатерии, а формулы и правила расчетов бухгалтер сможет поменять сам на языке "похожем на обычный русский". Первая часть - вытеснение конкурентов - прошла успешно. Вторая - как-то не очень. Я бы даже сказал, что бухгалтер без поддержки программистов сейчас еще беспомощнее чем в начале 2000-х. Тогда все-таки и формы учета были попроще, и правила налогового учета во многом совпадали с бухгалтерским - так что всегда был бэкап-план в виде журнально-ордерной системы учета...
Скажем прямо - что было до того, в регионах воспринималось как очередной (но вполне рядовой) бзик в отношениях между руководителями РФ и Украины. Они и до того непрерывно что-то делили - то газ, то флот, то землю между русскими/украинцами/татарами... Нам за 3000+ километров плохо было видно.
На самом деле, конечно, с позиции сегодняшнего дня - видно что спусковым крючком была обратная рокировочка в стиле: "Давай пока твоим мужем Володя побудет, а потом опять я", разгон протестов и поездка императора ПуИ в Кремль по пустым улицам. Экономика без политических свобод уже почти не росла, технократические решения типа повышения пенсионного возраста давили на популярность - и в голове царя зашептал голос: "Нам нужна маленькая победоносная война...". Тем более, что временщик Дима имел в активе формальную победу в такой войне 2008 года (и хотя все пока славили великого кормчего как архитектора этой победы отводя Диме только техническую роль - кто его знает как может это повернуться со временем ? Нет - надо обязательно чтобы была своя...).
Кстати, я считаю что и ко второй войне 2022 года спусковым крючком были события в Беларуси и откровенно травоядная позиция Европы и США. Царь убедился (а придворные - радостно подтвердили) что запад как никогда слаб, и достаточно чуть-чуть надавить чтобы смазанная победа 2014 года (вкупе с хозяйственными проблемами типа крымского канала) превратилась в полную и окончательную. Оно, понимаешь ли, хотело лежать в мавзолее на правах исправителя ошибок советских генсеков и быть в учебниках истории чем-то средним между Наполеоном и Екатериной нашей второй... :-(
В регионах, опять же, одобрения никого не спрашивал - поставили перед фактом. Абсурдно думать, что условные омичи рады что за счет их нищего бюжета чинят дороги и свет в условном стаханове...
Парадокс конфигурации Тьюринга. Чтобы избавиться от программистов, кастомные решения написанные на языке программирования высокого уровня - заменяются на коробочные. Любое коробочное решение требует конфигурации, чтобы быть применимым для максимального круга клиентов. Конфигурация со временем непрерывно усложняется, пока не станет равномощна вычислительной машине Тьюринга. С этого момента, конфигурация становится высокоспециализированным языком программирования (или вычислительной системой) с отвратительным обеспечением инструментами, без нормальной отладки и с очень узким коммьюнити. Чтобы разобраться как настроить систему используя средства тьюринговой конфигурации, приходится нанимать специалиста по программированию... Круг замыкается.
У меня другие данные. Первый удар был в 2014 году, как сбили нидерладнский Боинг и скакнул курс доллара. До этого, разница в зарплатах разработчика на внутреннем и зарубежном рынке была процентов, ну... тридцать. И на аутсорс надо было знать английский, а на внутренний - нет. А тут зарплаты стали различаться этак раза в два, два с половиной... Второй удар - это когда окологосударственные корпорации решили уйти от традиционной модели "вендор-заказчик" и решили втянуть в себя ит, создав центры разработки типа Сбертеха. Норма прибыли госбанка настолько выше нормы прибыли любого реального бизнеса в регионах - что уже в этот момент специалисты на производственных предприятиях тупо начали заканчиваться - и началась зарплатная гонка. Ковид - это, я бы сказал, уже самый конец истории... Да, понятно, что удаленка немного ускорила эти процессы позволяя наняться из глубинки на московскую позицию. Однако, не надо обольщаться - московские деньги в регионе радуют только временно. Потом внезапно выясняется, что когда у тебя зимой не чистят толком снег кроме как в центре, весной стоит вода с говнами по колено на улицах, парк вырубили под торговый центр друга губернатора, в местной поликлинике почти нет врачей-специалистов, общественный транспорт разрушен, а дороги каждый год выглядят так как будто их бомбили фашисты с хенкеля - зарплата уже не радует. И это еще не пошли дети в школу (поставьте новые окна, купите краску для доски, сбросьтесь на ремонт крыши и далее по тексту - причем, учителя тоже деградируют и вы учите детей сами дома)... Дальше специалист смотрит, вздыхает, и едет в МСК. СПб или на худой конец на юг. А оттуда в Европу или Штаты. Исчерпание человеческого капитала...
Более того, я сам из яростного патриота родного региона в какой-то момент превратился в пессимиста и циника. А всего-то я сделал прикидочный расчет - во сколько обойдется всех сибирских разработчиков перевезти в МСК или СПБ (метрополию), в сравнении с ежегодными затратами на инфраструктуру чтобы оставить их со сравнимым качеством жизни в Сибири...
Бессмысленно обвинять в этом удаленку или какое-то еще разовое событие. То что вы описываете - "ни программистов, ни аналитиков она не может найти от слова совсем..." - это уже самый финал процесса, который называется "исчерпание человеческого капитала". Мы прошли длинной дорогой... В 90-е годы на улицу было выброшего гигантское количество инженеров из ВПК (и - всегда привожу эту историю: на фоне многомесячных неплатежей зарплаты в оборонке сибирского миллионника, банки спокойно искали, и находили! - уборщиц (!!!) с высшим образованием). В сочетании с феодально-колониальной моделью развития страны (Москва и отчасти Питер - метрополия, остальное - внутренние колонии с местными царьками и/или назначенными губернаторами) - это гарантировало отсутствие ресурсов для развития на периферии страны. В результате, регионы выживали ровно тем чем написано - проедая советские основные средства в первые годы, и человеческий капитал во все последующие. Ученые делали доклады об этом все нулевые годы, и все десятые. Кого это волновало ? Никого: проблемы негров шерифа не волнуют... Если бизнесы в регионах только сейчас осознали что они не выживут - это только их недальновидность. Впрочем, многие вполне себе подозревали это и раньше: поэтому выжимали из регионального бизнеса все соки, и тащили деньги в офшор. Чем, конечно, еще сильнее подрывали воспроизводство человеческого капитала. В сухом итоге - регионы РФ будут деградировать и подыхать еще быстрее чем раньше. Жить будут только те, кому денег подкидывает федеральный центр (в зависимости от коньюнктуры). Более того, деградация и обезлюдивание регионов воспринимается федеральным центром положительно, так как чисто по бухгалтерии это позволяет сократить дотации. Потом это либо придется реколонизировать еще раз при нормальной власти, либо это успеют сделать соседи, и РФ станет сильно меньше по площади, чем мы привыкли видеть на картах. Волнует ли это правящие элиты ? Конечно же нет. Их интересуют только те регионы в которых можно добывать природные ресурсы на экспорт, и население которое требуется для обслуживания этой деятельности (а в идеале - трудовые мигранты вахтовым методом). Я не идеализирую советскую власть, но она ставила задачу обживать регионы за Уралом. Нынешняя власть такой задачи не имеет...
Принтер, практически как любой другой станок - не имеет смысла сам по себе. Он приобретает ценность только тогда, когда встроен в конкретную производственную цепочку. Смотрите: основное достоинство принтера это быстрое изготовление прототипа или оснастки. Если мне "вотпрямщас" понадобился шаблон для сверления с расстоянием до края 11.3мм - я его за 10 минут напечатаю на принтере и тут же пущу в работу. Как только мы включаем в эту цепочку стороннего поставщика - 10 минут превращаются в пол рабочего дня (и это в лучшем случае). В результате, ухудшение составляет 240:10 = 24 раза... Таким образом, для разовых заказов, сторонний принтер - ну такое себе!
Второе преимущество принтера - это низкие постоянные расходы (и соответственно, минимальная партия - "...от одной детали"). Нужно встраиваться в цепочки ремонта, которые требуют не слишком большой ассортимент деталей, и не слишком много - но регулярно. Клипсы какие-нибудь для автосервисов, не знаю что еще. После того как вы с ними отработали модель - они могут вам просто регулярно присылать заказ - чего и сколько, а вы будете печатать малую серию и отдавать.
Пожалуй, самое правильное что делают коллеги из статьи - это продажа сопутствующих услуг. Не надо продавать услуги печати, надо продавать решение проблемы. И в этом случае, ценник можно и еще задирать. Пока ваши услуги стоят дешевле чем простой оборудования пока запчасть идет из Китая (ну или из Москвы в регион) - заказчик будет платить и плакать от счастья.
Расскажу байку для закрепления пройденного. Если итальянец пошел покупать корову - значит он собрался делать и продавать сыр. Если российский крестьянин пошел покупать корову - он собрался сдавать молоко на завод по 3 рубля 20 копеек за килограмм (и каждый год подавать на конкурс чтобы ему на поддержание штанов дали субсидию от местного минсельхоза). Вот держать парк принтеров и печатать разовые заказы на авито - это сдача молока на молзавод, как ни прискорбно: всю добавленную стоимость забирает кто-то другой. Находите хорошие цепочки, и расширяйтесь вертикально - выдавливая конкурентов и занимая их место. Уже тот факт, что они приходят к вам за печатью и конструкторским ресурсом уже говорит об их интеллектуальной ограниченности. Так и какого черта?!
Нет, дело не в том, что дженералисты знают "всё ит". Эта эпоха кончилась, наверное, в 70-х. Дело в том, что они знают, как оно там работает под слоями абстракций и геологическими формациями библиотек. Потому что еще успели поработать на относительно медленных и проще устроенных системах ближе к железу. А разговаривая с относительно недавними разработчиками - я иногда не понимаю, как они вообще ухитряются выдавать годное. Ибо их базовые знания - либо чистая мифология и зельеварение (известно, что если хочешь полететь на метле - надо взять сушеную жабу, слизь саламандры, глаза жужелицы и варить на медленном огне 6 часов), либо сознательная слепота ("там тьма, ужас и монстры - я об этом даже не буду думать"). Мне это дико (благо я начинал с восьмибитных КР580ВМ80А, цельнотянутых i8080, и далее через все поколения персоналок и кусок промышленных контроллеров) - я бы повесился работать с системой, которая с определенного уровня становится магией, и с которой ты при всем желании ничего не можешь сделать. А молодым ничего, норм...
Впрочем, я сейчас еще одну интересную вещь скажу. Наблюдая за своими детьми, я обнаружил что они вообще к компьютеру относятся совершенно не так как я. Для них ПК - это бытовой прибор наравне с микроволновкой или чайником. Хотим разогреть пиццу - идем к микроволновке. Хотим в интернет или поиграть - включаем компьютер. А для меня, компьютер всегда был потрясающим приключением, которое хочется программировать. Впрочем, когда я поделился этим со своими родителями - они сказали, что история повторяется. Для них в институте - один калькулятор (Б3-18) в группе был подарком судьбы: вместо расчетов столбиком, логарифмической линейки и таблиц Брадиса - просто жмешь кнопки, и получаешь сразу ответ (втч логарифмичекие функции, экспонента, тригонометрические и обратные!). И они (если он попадал в руки) на нем считали, даже если не было особо и нужно! :-) А мы (их дети) уже относились к калькуляторам безо всякого пиетета, и без понимания что оно там внутри делает.
Да ну! Уж если народ на это шел - то обычно программировался контроллер дисковода через порты ввода-вывода... Кто ж серьезную защиту через bios будет делать...