В деталях приснился многослойный сюжет про то, как немецкий политолог, бывший АдГшник Альберт Шпер (то ли гордившийся тем, что его фамилия отличается на одну букву от фамилии известного архитектора, то ли наоборот, стыдившийся этого) написал сценарий антиутопического аниме.
Подробностей сюжета этого аниме не помню, но изображенный там мир сводился примерно к следующему — на обратной стороне Луны построены принадлежащие всяким Амазоногуглояндексам темные фабрики с 3д-принтерами и дарккитчены, на которых все делает поехавший искуственный интеллект, по недосмотру создателей воспитанный на шуточках про печку для 6 миллионов пирожков и анекдотах про Штирлица. Несмотря на то, что этот искуственный интеллект пытаются удаленно держать под контролем рептилоиды из бункеров в Антарктиде, он мало-помалу сходит с ума и объявляет себя космическим фюрером. Земля превращена в ядерную пустыню и поделена между враждующими группировками (теми самыми Амазоногуглами), которым еду и продукцию этих фабрик (каждому свое) доставляют сбрасываемые с орбитальных бомбардировщиков беспилотники.
Дальше этого политолога (понаехавшего, понятное дело, в Москву, у нас таких любят) предлагали то наградить литературной премией от портала «аффтар.сегодня», то наоборот, посадить за пропаганду всего — ну а завершалось все объявлением о том, что Гугл и Яндекс начинают новую космическую гонку для строительства датацентров в космосе.
Короче, берите готовый промпт, запихивайте в иишенку, а мне лень.
Вот кстати, небольшое отступление от записи про кроссфункциональность — но полезно его как-то осознать. Подумайте минуточку о полномочиях product owner’а в том виде, как они записаны в Scrum Guide. Оказывается, что это человек, который единолично определяет, что делает команда и зачем это нужно — то есть product goal, причем с очень широкими полномочиями относительно «продукта» — буквально «владеет» им, может внезапно решить, что цель протухла и надо бежать в противоположном направлении, или вообще прикрыть лавочку. Добавим к этому еще и способность команды сделать «продукт» от и до, ту самую «кроссфункциональность», и получим крайне стремную с точки зрения бизнеса ситуацию — есть руководитель, определяющий буквально все, касающееся продукта, есть команда, способная затащить сложную задачу, кто им мешает оформиться в отдельную ОООшку и послать всю организацию к ебеной матери?
Да, Матвейчев яркими примерами показывает, «Почему американцы побеждают» (обязательно перечитайте!), но обратите внимание, что относится это к политическому консалтингу, где, во-первых, игра зачастую идет в режиме «все или ничего», а во-вторых — время существования кроссфункциональной команды строго ограничено, после выборов она будет распущена безо всяких последствий. Обычный бизнес предпочтет как-то ограничить и полномочия «продакт-менеджера» (да, это уже не совсем product owner в смысле скрама, но по части определения целей они схожи), и обложить его творчество какими-то рамками, вот хотя бы даже возьмем пример с «согласованием у юристов» — пусть даже наличие отдельного юридического отдела замедляет работу, но оно же и ограничивает «владение продуктом». С точки зрения стабильности «бизнеса» нет ничего лучше обычной функциональной структуры — может быть, укрупненной, пример с раздельными «отделом фронтендеров», «отделом бекендеров» и «отделом тестирования» — это дичь (хотя часто встречающаяся), но в целом нормально выглядит структура R&D, когда условные «технари» собраны в один или несколько отделов, а все остальные вспомогательные по отношению к этому процессу функции — в функциональных подразделениях.
Впрочем, и тут есть забавные нюансы — например, такое разделение на «тематические» подразделения и «всех остальных» в Роскомиксе выглядело примерно так: есть «тематическое подразделение», сидящее на каком-то определенном внешнем заказе или типе заказов, в этом отделе собраны формально все необходимые инженеры, конструкторы, программисты, техники, … — в общем, все технические специалисты. Если тематическому подразделению надо что-то купить — то отдел закупок один на все предприятие, надо идти на поклон туда; согласовать договор с внешним контрагентом — к юристам; отправить официальное электронное письмо — тоже процесс, требующий одобрения от соответствующего подразделения. Разумеется, компетентность «общих» для всего предприятия закупщиков или юристов была ниже плинтуса. Скажем, чтобы купить достаточно дорогой прибор, надо было самостоятельно собрать три коммерческих предложения от разных поставщиков, подготовить проекты договоров, … — то есть буквально выполнить работу отдела закупок, да еще и объяснить контрагентам, что это пока так, собираем предложения, а когда купим — хер его знает. В итоге оказывалось, что в «тематическом» подразделении есть люди, числящиеся «инженерами», но фактически занимающиеся закупками, договорной работой, или даже буквально маркетингом — от поиска клиентов до организации стендика на отраслевых мероприятиях (да-да, вот вам и полная «кроссфункциональность»). Про «теневое IT» и «серую кассу», наполняющуюся самым невыгодным для родного завода образом, думаю, не стоит даже и задумываться :)
И второе очень сложное требование к product owner’у — кроме определения product goal, цели «с точки зрения бизнеса», этот же человек должен заниматься работой с «беклогом», то есть списком задач, причем обычно крайне «узкотехническим». Фактически, нужно сочетать в одном человеке две совершенно противоположные вещи, а это встречается крайне редко. Более того — для выходца «из менеджмента» все правила скрама покажутся детской возней в песочнице, особенно — когда начнется игра в planning poker. Для выходца «из технарей» — наоборот, совершенно неподъемной окажется «управленческая» работа (которая скрыта за словами вроде communicating, буквально «донести до команды необходимость выполнить задачу»), да и по части целеполагания возникнут вопросики.
И кстати, в достаточно большой организации не поможет и внедрение Scrum’а «сверху», которое обычно происходит, когда кто-то из руководства решит прочитать что-то о «революционном методе управления проектами» — потому что противодействие возникнет и на уровне «среднего менеджмента», тех самых кандидатов в product owner’ы — потому что вместе с офигенными полномочиями на «владельца продукта» свалится и офигенная ответственность, а суть карьеры многих «управленцев» как раз и состоит в избегании любой ответственности, местами — буквально по разделу General Interference with Organizations and Production из Simple Sabotage Field Manual. В результате у всех причастных возникает желание «все поменять, ничего не меняя», и поэтому внедрение Scrum обычно сводится к следующему — открываем Scrum Guide, внимательно читаем, вычеркивая обязанности и полномочия «по существу» — а с другой стороны, уделяем параноидальное внимание «ритуалам». Нет ничего проще «внедрения Scrum» в «функциональной» команде — скажем, состоящей исключительно из тестировщиков — просто добавляем в календарь бессмысленные «дейлики» и раз в две недели — «планирование спринта» (которое сводится к определению, сколько типовых задач из Jira можно будет переложить из графы «надо сделать» в графу «сделано»).
А в следующий раз — напишу немножко про «матричную структуру» — которую, внезапно, у нас толком не понимают, и совершенно шикарный способ ее поломать :)
Хотел недавно обсудить с юными программистами, что такое «кроссфункциональная команда», о которой говорит нам Scrum Guide, но неожиданно обнаружил, что «работающие по скраму» молодые люди с основными положениями этой методологии не знакомы — но не пропадать же заготовленной проповеди? Тем более, не далее чем сегодня в телеге наткнулся на пару обсуждений нашего будущего с иишенкой или без — и тут тоже есть, что сказать.
Начнем, разумеется, с первоисточников — а именно с формулировки из Scrum Guide, где обсуждается, как должна быть устроена «команда», цитирую:
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
Программисты и вырастающие из них малокомпетентные руководители любят ее извращать (одновременно притаскивая еще одну фразочку — Scrum recognizes no titles for Development Team members other than Developer — из старых версий руководства, в версии 2020 года ее убрали, потому что она создавала сложности с пониманием) — мол, каждый член команды должен обладать всеми необходимыми навыками, а поэтому можно вешать любому какие угодно задачи, и может быть, в программировании это и так — но вот давайте посмотрим на процесс разработки несложного электронного устройства, лучше даже чего-то IoT’шного. Возьмем простой метод:
Прикиньте на пальцах количество направлений, в которых вам надо иметь компетенции. Умножьте на два. Получите число людей, которых вам надо собрать в коллектив и удерживать в нем для того, чтобы обеспечить стабильную разработку.
Какие специалисты понадобятся для этого, кто будет «работать руками»? Загибайте пальцы:
— надо уметь разрабатывать принципиальные схемы;
— надо уметь трассировать печатные платы (да, это немного другая специализация, иногда один человек умеет делать и то, и другое, иногда — нет);
— надо уметь программировать под микроконтроллеры;
— надо уметь программировать под «desktop» (в кавычках, потому что это могут быть и какие-то cli-утилитки, и gui-шные приложения, и вообще что угодно, типа питоновского скрипта для автоматизированного тестирования);
— надо уметь программировать бекенд для веба;
— надо уметь программировать «фронтенд» (опять же, название условное, это может быть и классический веб-сайт, и приложение на Android);
…
— заметьте — я уже перечислил чисто технические специальности, при этом пальцев на одной руке уже не хватает, а на выходе мы получим «продукт, сделанный программистами» — так что добавьте сюда пару дизайнеров («индустриального» и веб-); конструктора и/или технолога, если аппаратная часть представляет собой что-то сложнее ардуины; быть может, вам понадобится несколько тестировщиков; в конце концов, кто-то должен в конечном итоге этот ваш «продукт» продать, так что давайте не забывать и про Business Development, Sales and Marketing. Ах да, я не упомянул самого главного — кто-то должен представлять себе, что же в итоге мы хотим получить, и как-то организовывать работу этой толпы — то есть никак нельзя обойтись без менеджера проекта, или в скрамовской терминологии — Product Owner.
Разумеется, это не имеет ничего общего с «кроссфункциональностью» в ее извращенном понимании, инженер-электроник, занимающийся трассировкой печатных плат, никогда не сможет хотя бы удовлетворительно писать бекенд-приложения, например — а бекендер вряд ли справится с задачей «перерисовать принципиальную схему ардуины, добавив вот то и убрав это». Кроссфункциональность в организации команды здесь противопоставляется функциональному делению — немного на другом примере разница описана у О. Матвейчева в «Уши машут ослом» — прочитайте главку «Почему американцы побеждают», там кроссфункциональный принцип описан в разделе про «принцип спагетти» и противопоставляется «пирамидально-функциональному», когда каждое отдельное направление выделяется в отдельное подразделение со своим руководителем — скажем, в гипотетической большой фирме, разрабатывающей много вышеописанных IoT’шных проектов, был бы выделен отдел схемотехников, отдел программистов (а может быть даже два, а то и три разных), обязательно — отдел тестировщиков, и так далее. Дальше в каждом таком отделе начинают «внедрять Agile» — и получаются именно характерные для такого подхода команды из одинаковых взаимозаменяемых узких специалистов, «людей-функций»; взаимодействие между командами максимально затруднено. С другой стороны, когда «все члены команды обладают одинаковыми навыками» — именно эти одинаковые навыки объявляются «всеми необходимыми». Для типовых хорошо формализуемых задач, вроде конвейерного аутсорса всяких оперденей для внешнего заказчика, оно может даже работать — но к кроссфункциональности, к «принципу спагетти», это никакого отношения не имеет.
Кстати, вопрос — а кто конкретно в Scrum отвечает за то, что команда обладает необходимыми навыками, кто должен следить за этим и при необходимости принимать кадровые решения — нанимать недостающих специалистов, организовывать обучение имеющихся, и так далее?
Но впрочем, из мира больших компаний давайте вернемся к всякой мелочевке, буквально к стартапам :) Типовой путь разработки того же IoT’шного устройства в мелкой фирмочке выглядит примерно так — есть один «гениальный директор/генитальный конструктор», который и в инженерии имеет довольно широкий кругозор (как минимум способен удовлетворительно, «на троечку», закрыть сразу несколько пунктов из перечисленных выше), и сумел ухватить какую-то чисто бизнесовую идейку, которую «закрыл» самостоятельной (или буквально с одним-двумя единомышленниками) разработкой востребованного на рынке прибора. А дальше начинается боль, потому что «техническую» сторону вопроса хорошо бы кому-то скинуть делегировать, «генеральный конструктор» смотрит на узких специалистов и офигевает — хотя это я уже описывал!
И вот тут нам на помощь приходит современная ИИшенка! Говорят, что всякий там Claude Code вполне успешно заменяет «младшего разработчика», который по достаточно точным указаниям в несколько итераций может реализовать несложный изолированный кусок кода, к которому не предъявляется каких-то специфических требований. Превратить CLI в GUI? Можно дать задачку «инженеру-программисту 3 категории» (он же «джун») — а можно скормить ее иишенке и получить результат ничем не хуже. Какая-то мелкая автоматизация, «типовой» код, в конце концов, тот же boilerplate — в общем, задачи, хорошо формализуемые и не требующие понимания «проекта в целом» уже не требуют участия узкоспециализированного программиста, к тому же иишенка не жалуется на жизнь и несправедливость мира, который не желает оценить по достоинству творческую работу «программиста под Android» (которая сводится, скажем, к превращению текстового описания апишечки в более формализованное, на каком-нибудь Retrofit).
Так вот, большинство действительно успешных применений LLM’ок — это замена редко нужных узких специалистов их иишным «аналогом». В сущности нет разницы между программистом, берущим задачку из Jira, а затем отдающим ее на code-review, и делающей то же самое нейросеткой (забавно, кстати, что это по сути перевод с человеческого языка в код, а именно для перевода LLM’ки и были придуманы); чем лучше формализуется такая задача, тем проще отдать ее железному болвану. И вот тут вырисовывается интересный критерий, как определить, заменит ли вас ИИ или нет — если в вашей работе в какой-то степени требуется давать указания подчиненным или коллегам, а потом проверять результаты работы — то ИИшенка заменит скорее коллег или подчиненных, но не вас; а вот если ваша работа, как программиста-кнопкодава, сводится к перекладыванию карточки на канбан-доске из графы «в работе» в графу «можно проверять» — то у меня для вас плохие новости!
Ну и да, плохие новости у меня для тех кнопкодавов, которые занимают агрессивно-оборонительную позицию по отстаиванию «своей зоны ответственности». Скажем, какие перспективы у условного «аишника», который практически демонстративно отказывается от изучения предметной области, не хочет отличать Telnet от TCP и вдаваться в нюансы маршрутизации в IP-сетях? Если «аишная» задача ставится и проверяется в терминах, понятных сетевикам — то какая этим сетевикам разница, будет ли построенная ML-модель сделана белковым data scientist’ом (это такое модное название для программиста на Python, который умеет перекладывать данные между Pandas и Torch) или нейросеточкой? Да собственно, никакой.
Немножко меня эта тема триггернула, так что продолжу :) В комментариях телеги написали, что оснащение лабы отличное, человеку понадобилось плату изготовить — и он принес герберы на флешке, за полчаса плату отфрезеровал и тут же запаял! Что же, разберем подробно возможности того оборудования, что мы видим на снимках.
Но для начала — маленькое лирическое отступление. Практически всегда, если оснащение такой мастерской выбирают люди, от тематики далекие, оно делится на две категории. Первая — «дорого-богато», и к ней в этой мастерской относятся, например, металлообрабатывающие станки марки Optimum. Бренд, разумеется, псевдонемецкий, на самом деле они полностью аналогичны китайской продукции, продающейся под десятками брендов — от чисто алиэкспрессовских Weisan, Numobams и Fusikaya до имеющих какое-то представительство в РФ марок вроде Корвет или Metalmaster. На форуме Chipmaker даже есть списочек «близнецов» в разделе «Китайские хоббийные станки«. Optimum, правда, на этом форуме не обсуждают — угадаете, почему? Но про металлообработку поговорим при случае как-нибудь в другой раз, сегодня — про электронику.
Пример бессмысленно дорогого оборудования в этой категории — это как раз станок для фрезеровки печатных плат, LPKF Protomat, в 2019 году стоивший около 1,5 миллионов рублей. «Коммерсанты», считающие деньги, подобным оборудованием пользуются редко — а вот в вузах, ЦМИТах, «Кванториумах», всяких конторах, кормившихся вокруг WorldSkills этот станочек был безусловным хитом (нет-нет, никакой коррупционной составляющей). Чисто для понимания порядка величин — даже в считающемся недешевым «Резоните» небольшой заказ на производство однослойной печатной платы без маски обойдется в сумму около 1500 рублей (причем большую часть стоимости будет составлять «подготовка производства»). Что лучше, один Protomat или 1000 заказов в Резоните? Будучи руководителем небольшой фирмы, разрабатывавшей всякую электронику, Олег Артамонов писал на Хабре:
На данный момент лично у меня там 177 выполненных заказов и один — в процессе. Минимальная партия из того, что мы там заказывали, составляла 1 штуку, максимальная — несколько тысяч штук.
Думается мне, что «Резонит» мог бы спокойно продавать абонементы на изготовление плат по цене Protomat’а, или провести акцию «Разбей Protomat кувалдой и получи пожизненную скидку!», и даже не обеднеть! :) А статью Олега прочитайте, потому что дальше ее немножко дополню.
Но сначала — про вторую категорию оборудования, «говно на сдачу». Что мы видим на фотографии ниже?
Молодой человек паяет на обычном «столе для персонала» (ESD вышло из чата, хоть на других фото и видно браслетики, купленные в рамках карго-культа), вместо хотя бы силиконового коврика с алишечки на столе в качестве негорючего материала лежит кафельная плитка (надеюсь, не оторванная от стены в ближайшем сортире). Паяльная станция — самый дешевый Element, со всем известными недостатками. Паяет чувак, разумеется, так, как это было описано в книжке для страдающих от дефицита советских радиолюбителей, тыкая паяльником в кусок вонючей канифоли и таская припой на жале. Открою секрет — уже более 80 лет используется припой с трубкой флюса внутри:
Его на жале паяльника таскать не надо и даже вредно, флюс от этого просто выгорает. Термоусадку, кстати, тоже не завезли, вместо этого — плохо накрученная синяя изолента. Дополнительное освещение и лупа установлены так, что пользоваться ими просто неудобно — поэтому «монтажник» сидит, скрючившись.
Ручной инструмент — разумеется, Dexell из ближайшей леруашки, зачем эти пассатижи на рабочем месте монтажника — хер знает, там нужны нормальные стриппер (Proskit 8PK-3001 или что-то типа того) и кримпер (тут сложнее, но какой-нибудь SN-58B с алиэкспресса закроет большую часть потребностей — большинство Molex, крупные JST, «Dupont» с некоторыми нюансами). Вытяжек на рабочих местах, конечно, тоже нет, даже «номинальных» китайских вентиляторов, потому что зачем?
В этой категории выбор оборудования и расходников полностью описывается «правилом сарая для велосипедов» из законов Паркинсона — выбор Protomat за много денег не обсуждается, а вот остальное — ну каждый же прекрасно понимает, что самый дешевый набор инструментов Dexell ничем не отличается от какой-нибудь Ombra или Jonnesway, а если нет разницы — зачем платить больше? Вот и выбирается оборудование «любительского» класса, причем даже нищебродско-любительского, более-менее продвинутый паяла взял бы, может быть, и станцию с картриджными жалами, и нормальный ручной инструмент, и даже термостойкий силиконовый коврик с алишечки. Кстати, и выбор «производственной» мебели подпадает ровно под это же правило — те же стулья взяты из самой-самой дешевой линейки, и при активной эксплуатации быстро разваливаются.
В итоге получаем «монтажный участок», прекрасно подходящий для пайки выводных компонентов, крупных разъемов и прочего подобного говна, мечту радиолюбителя-нищеброда, дополненную дорогим, но прикольным сверлильно-фрезерным станком по текстолиту. А вот чего не хватает точно — это оборудования «промежуточной» категории, которое дилер LPKF не предложит, а занимающийся закупками представитель вуза даже понятия не имеет, что такое есть.
Например, SMD-компоненты паяльником не паяют (с), но можно относительно недорого оснастить лабораторию режущим плоттером для изготовления трафаретов (пассивка вплоть до 0603 и микросхемы с шагом выводов до 0,5 мм получаются приемлемо), самым простеньким ручным принтером для паяльной пасты с алиэкспресса и «печкой» типа T-962 — такой комплект обойдется в сумму порядка 50 000 рублей (если брать за свои и экономить), или тысяч в 100 — если деньги можно тратить, особо не оглядываясь. Например, что-то подобное получилось у американцев в том же 2019 году — просто при комплектации лаборатории цель была не «освоить бюджет», а купить оборудование, подходящее для монтажа единичных, но «современных» устройств:
Я исключая из рассмотрения предложенные на хабре варианты типа «купить электродуховку, ардуину и твердотельное реле» — они явно не найдут понимания у вузовской администрации (хотя можно пропихнуть в формате «студенческого проекта» в том же МИЭМе — что, правда, не снимает вопроса «кто будет отвечать, если ваша электродуховка загорится»). Но из «самостроя» — можно дополнить вышеозвученное совместимым с OpenPnP pick-and-place-автоматом, по сложности он не отличается от заебавших всех 3D-принтеров, но намного, намного полезнее! Можно обойтись и готовым чем-нибудь тысяч за 150 с алиэкспресса — но тогда в хороший студенческий проект превратится доведение этого полуфабриката до ума.
Кстати, раз уж вспомнили о пожарной безопасности. Есть еще одно занятное последствие решения «оборудуем лабу всяким говном за три копейки», применительно, например, к вот этому рабочему месту монтажника: похожая паяльная станция стоит от 5 тысяч рублей, остальные аксессуары — тоже копеечные, поэтому у других вузовских лабораторий появляются собственные неучтенные «наборы монтажника» (я в МИЭМе точно знаю два, старательно спрятанные от проверяющих) — просто потому, что никакой разницы нет, но в «инновационную мастерскую» бегать не надо. При этом пожарная безопасность выходит из чата — если в «централизованной» лаборатории еще можно проверить, что в конце дня все паяльники выключены, то в каком-нибудь закутке компьютерного класса забыть включенную паяльную станцию — элементарно!
В качестве несложного упражнения для читателя: как понять, что в мастерскую студентов пускают лишь «по большим праздникам», а пользуется ей в своих целях дед-вахтер, которого туда посадили, чтобы студенты, не дай бог, ничего не сломали?
Более сложное упражнение — найдите хоть одну фотографию, от которой не хочется сделать facepalm :)
