Pull to refresh
98
0
Send message

Здравствуйте, здравствуйте! Всегда рад видеть человека, который с реальными клиентами в РФ общается. :-)

Мой опыт сильно пересекается с тем, что написано. Я вижу две причины:

  • Тотально безобразное качество менеджмента. До тех пор, пока студентам на кафедре менеджмента будут говорить, что они могут управлять чем угодно: от кофейни до атомной электростанции, и они этому будут верить (и что самое страшное - им будут верить их работодатели) - ситуация не изменится. Менеджеры рисуют красивый процесс "как в учебнике". Исполнители крутят пальцами у виска, но так как зарплату им платят за выход годного - придумывают свой процесс (иногда внешне как-то совпадающий с тем, что описывает начальник - в тех точках в которых начальник его проверяет). Начальник получая обратную связь от своего руководства что вверенное подразделение работает нормально - еще больше убеждается в своей способности "выстраивать процессы". Потом он сам учит этому других. Круг замыкается.

  • Культура производства, ориентированная на людей, а не на процессы. Это я уже не знаю - почему... В подсознании людей (и руководителей и исполнителей) сидит миф, что надо найти правильного человека, и все будет работать. Соответственно, все ошибки персонифицированы и наказываются (мотивация у нас такая: пряник черствый, и им тоже бьют). В результате, все - всем врут. Одни врут что моют оборудование согласно регламента. Другие врут что берут смывы как положено. Третьи пишут нужные цифры в журнал без анализа (ну или почти без анализа). Но на бумаге и в докладах - у всех все ОК. Как при этом никто не травится - загадка. То-ли кто-то консервантов кладет больше чем положено по рецептуре, то-ли бог все-таки дураков специально охраняет от неприятностей. Попытка заставить соблюдать все процессы в этой ситуации приводит к немедленному параличу переходящему в кому.

Что с этим делать ? Понятия не имею. Учить и повышать культурный уровень. Рано или поздно (не обольщайтесь - скорее поздно, особенно в условиях "военной экономики") человечество докажет что способно обучаться и становиться лучше...

Господи, но если же вы на T&M - вам какая разница как заказчик хочет переформулировать задачу ? Если вы в Agile - то это не то чтобы хорошо, но нормально: по мере того как проект пошел - у заказчика начало появляться понимание, что ему реально нужно. Берете продукт-оунера с его стороны, чистите бэклог от неактуальных задач, добавляете актуальные, и погнали спринты. Если это T&M - вы зарабатываете денежку каждый спринт и каждую фичу которую сдаете. Поэтому вы готовы хоть бесконечно все это менять и бесконечно разрабатывать. Если заказчик хочет сокращения сроков - увеличиваете цену и размер команды... Вот если бы у вас был фикс-прайс, то тогда да могла бы быть трагедия.

Ну круто, что сказать... Мы пока до такого не дошли. А теперь уж наверное и не дойдем. :-(

Ну вот так - у нас же не опен-спейс а рабочая комната на несколько человек...

Ну, скажем 200-400 это уровень домашней мастерской или клуба "умелые руки". 2-4 канала с честными 300Mhz полосой пропускания это уже бюджет 1500-1900. А к нему еще бы лабораторный источник питания, генератор сигналов, настольный мультиметр вместо "цешки". А потом захочется сдуть с места резистор чтобы оторвать ногу контроллера от нагрузки, что тащит паяльную станцию с феном, а там недалеко до нижнего подогрева... Нет, в принципе я согласен ВСЕ это иметь дома - но тогда надо переходить на стиль жизни аристократии и апгрейдить 3-х комнатную квартиру на 5-6 комнатную. Однако, за отсутствием фиансов - приходится обустраивать "уголок электронщиков" в офисе...

Интересно. Я видел только как удаленно UI телевизора тестировали. В лабе был телевизор, на него смотрела камера, и имитатор пульта с веб-интерфейсом. Но это все-таки больше верификация когда в эмуляторе прошивка уже проверена. Представить себе отладку платы с осциллографом, генератором сигналов и парой-тройкой мультиметров - мне уже сложно. Или этап начальной отладки уже пройден, плата поставлена в какой-то вариант test-jig, и нам достаточно тест-поинтов чтобы лить прошивку или переключать JTAG - тогда наверное еще как-то. Понятно что когда оно супер-миниатюрное или супер-компактное - то тоже особо иголками мультиметра не потыкаешь. Но в ситуации общего применения - возможность ткнуть в любое место пробником или пальцем понять "греется-не греется" - может экономить человеко-дни, если не недели...

Я думаю, это зависит от задач и от принятой рабочей культуры. У нас не было принято сидеть в наушниках. Скорее даже - если человек надел наушники - это сигнал что он занят и просит его кроме как в чрезвычайной ситуации не беспокоить. Ну или ненадолго одеть наушники чтобы что-то быстро посмотреть/послушать не отвлекая других. Но опять же - у нас это была преимущественно промышленная автоматизация (местами довольно близко к железу). Там не получалось набрать задач на спринт, и потом тихо сидеть уткнувшись в монитор. Тут клиент позвонил - надо посмотреть удаленно, там люди приехали после тестового прогона - надо обсудить. Здесь встретились с проблемой - надо быстро решить в какую часть системы загнать workaround... Когда уходили на удаленку на ковид - было тяжело. Как только дали возможность - вернулись обратно. Вообще, возможность показать проблему вживую и тут же на листе бумаги или на доске набросать схему и найти решение - бесценно. Ну да, в том же тимсе можно добавить вайтборд - но рисовать мышкой такое извращение... Ну или надо всем покупать дигитайзеры. Или завести архитекта на полную ставку чтобы он рисовал, а на митингах только одобрять или замечания высказывать. Но это все время... время.

На контрасте я наблюдаю другую команду где как раз почти все на удаленке. И это тот случай, когда 15 человек делают то, что мы делали вчетвером-впятером - и тратят на это в два раза больше времени. Хотя, конечно, у них бесконечный запас по устойчивости. Если бы в старой команде любой человек ушел - это была бы трагедия. Из этих 15, треть пропади - отряд не заметит потери... Может через месяц на коллах начнут интересоваться, чего это у такого-то отпуск так затянулся... :-)

Тут есть два варианта. Или даже три:

  • Вы переходите на западный стандарт управления проектами (и на западные же бюджеты и норму прибыли). В этом случае вы можете нанять хоть пятнадцать, хоть двадцать человек рассеянных по куче часовых поясов, тратить 30-40% времени на коммуникацию - и полгода делать то, что команда из 5 человек на гибриде сделала бы за три месяца. Но вам пофиг, потому что вы сказочно богаты, а еще люди в регионах обходятся дешевле и вы получаете отдельную премию за формальную экономию фонда заработной платы.

  • Вы организуете филиал в регионе, и набираете персонал оттуда. При этом они имеют у себя гибрид чтобы работать эффективнее. Вам с ними гибрид не нужен, достаточно синков по видеосвязи. Я такое видел когда был проект у US и у ребят из Сибири. С обеих сторон были выделены лица, занимающиеся синхронизацией, и непосредственно вся команда US с целой командой RU взаимодействовала редко.

  • Наконец, вы можете использовать высококвалифицированных (!!!) специалистов на удаленке для решения конкретных задач. Принцип здесь тот же, что и при взаимодействии с фрилансерами. При этом они у вас всегда будут немного сбоку команды (особенно, если остальная команда имеет гибрид или офис, а удаленщик - нет). Потому что быстрый обмен мыслями между столами, в курилке, в кафе или у кулера, увы, никто не отменял.

Если же у вас ограничен бюджет, работать надо быстро, команда небольшая, и задачи меняются - на круг дешевле нанять людей так, чтобы они в реале пересекались хотя бы 1-2 раза в неделю. Это сильно расширяет доступную географию (особенно в случае 4+1) - тут можно хоть на поезде 4 раза в месяц приехать, но оставляет возможность в офисе интенсивно решить накапливающиеся вопросы. 3+2 уже сильно хуже по географии, но и сильно лучше по эффективности коммуникации. Что в какой ситуации предпочесть - вопрос открытый, и скорее всего, однозначно не решаемый. Зависит от коньюнктуры, да и меняется в процессе...

Да, добавить бы такой пункт в опрос. Лично я в пандемию увидел следующие эффекты:

  • Невозможно вне офиса разумно огранизовать работу - если помимо ноутбука/ПК нужна специфическая аппаратура. Сначала домой едет, например, контроллер, а к нему источник питания, сетевой коммутатор и провода. Потом оказывается нужен осциллограф. А через день еще и анализатор сигналов чтобы понять, чего это у нас протокол криво ходит. Пневмоцилинр давать домой опасно (может, например, детю череп пробить при неудачном стечении любопытства и обстоятельств), да и места нет - приходится собрать имитатор... А потом это надо все другому человеку - если возить, то потеряют, а стоимость всей этой обвязки легко в разы превышает стоимость самого компьютера. Дешевле в офис ходить в таком случае.

  • Удаленка сколько времени дает (убираем дорогу), столько и отнимает (добавляем созвоны). Если нет регулярных созвонов - команда начинает разваливаться. Рабочее совещание в офф-лайне по моим наблюдениям - сильно эффективнее аналога в он-лайн. Хотя бы за счет того, что можно быстро перекинуться словом с соседями пока кто-то другой говорит. В онлайне это надо делать через чат, что сильно дольше, сильно публичнее, и часто не имеет смысла. Соответственно, если мы собрали 5-6 человек, то при условии что каждый выскажется по 60 секунд, ответит на вопросы и уточнит - это уже минимум 10-15 минут. По три раза - вот уже и 45 прошло... А работать когда ?!

  • Однако - если фирма склонна к бессмысленным совещаниям, где один человек вещает о том как космические корабли бороздят межплатентное пространство, а остальные тоскливо ждут когда все это закончится - то удаленная работа эффективнее. Потому что сотрудники выключают камеры, убавляют звук, и занимаются чем-то полезным.

  • Джуны на удаленке отваливаются. В офисе за джуном можно коллективно приглядывать, и вовремя заметить что у него начали стеклянеть глаза, и он не знает что ему дальше делать. При этом достаточно проходя мимо стола (или в столовой) узнать в чем дело и подсказать, то на удаленке все плохо. Или джун будет постоянно звонить/писать - и отрывать других от работы, или - он будет сидеть в состоянии кататонии до планового созвона с наставником/бадди. Первое очень дорого, второе - бессмысленно. В итоге, можно ставить крест на пирамиде сеньорити и возникает риск "разрыва поколений", когда толпы джунов не могут никуда устроиться, а в это же время на проекте некем закрывать вакансию мидла повышающегося до сеньора (или переходящего на другое место работы).

Поэтому таки да, я за гибрид. Какой он будет: 3+2 или 4+1 (а также дни присутствия) - пусть решает сама команда.

Здесь вопрос только в ширине канала связи, который мы согласны потенциально оставить. Потому что в пределе, полностью заблокировать его можно только с прекращением любой полезной работы. Когда мы говорим не о бандитах-шифровальщиках, которые вытаскивают к себе на сервера максимальный объем данных (ибо всегда есть риск что у людей есть бэкапы, и тогда надо отбивать затраты хотя бы продажей информации на черный рынок) - а о реальном кроте, имеющим соответствующую квалификацию и работающим на таких же профессионалов за пределами страны - он может использовать широкий спектр скриптовых языков для того чтобы одноразово выполнить алгоритм стеганографии - начиная от доступных ему по служебной необходимости питона или "C" или "Java" - заканчивая какой-то экзотикой в виде javascript внутри браузера или макросов word/excel. Любая вычислительная система эквивалентная машине Тьюринга (несть им числа на современном ПК) способна решить задачу стеганографии (правда - с разной скоростью). В самом крайнем случае, специалист может вынести знания у себя в голове за территорию, там выполнить шифрование и скрытие в контейнер - выучить или распечатать текст в base64, и вручную его набить в файл. В целом, я скептически отношусь к возможности детектирования стеганографических каналов передачи данных, если это не школота балуется... Хорошо если вы сумели поймать in the wild две версии изображения или аудио, или видео - которые внешне одинаковые, а битовый поток разный. Тут можно хоть как-то предположить по времени, какое измененной и путем сличения с оригиналом получить разницу и ее статистически оценивать. Если же сволочь на той стороне умная, и скрывает информацию в уникальных потоках - это примерно как разгадывать шифр гаммирования с длиной ключа равной длине открытого текста: только ловить на operation errors и human factor. Иначе, IMHO, никаких ресурсов не хватит...

Ну в общем, мы примерно с одними заказчиками работали получается... :-)

Единственное я уточню по обратной связи. Большинство проектных методик (взять тот же PMBOK) предполагают что объективно существует (в головах у людей, либо даже без определенного носителя) точная картина желаемого будущего. И дальше вопрос заключается только в том, обнаружили ли мы соответствующих людей, и применили ли мы к ним правильные методики, чтобы этот образ вытащить и закрепить в виде документа. Дальше те, кто верят в исходный постулат будут бесконечно спорить о том, как правильно искать людей, какие вопросы задавать, как надо назвать разделы ТЗ, и в пределе - какие отступы от полей надо делать справа и слева.

Я - информированный пессимист, который уверен в обратном. В России (насчет EU/USA - там видимо ситуация другая, иначе они не родили бы все эти методики управления с ТЗ) конкретного образа будущего не существует. Так учит нас вся история начиная с 1991 года. Тут тебе и кризисы каждые 5-10 лет, тут тебе и неразвитость институтов, и ужимки и прыжки федерального правительства, и неквалифицированные управленцы, и модель страны центр-колония, и что угодно еще.

Поэтому мы, не поддаваясь иллюзиям, должны опираться вместо "образа желаемого будущего" на примитивный диагностический критерий: "Если пациент орет - значит ему больно!" (C) Стоматолог в СССР при пломбировке каналов. :-) Соответственно, проектная работа - это сбор информации где болит, и максимально быстрое предоставление новой итерации, чтобы снять карту - где теперь болит меньше, а где больше. Такой вот agile с оттенком садизма. Но по-другому пока не умеем, а работать надо...

Здесь надо просто поменять установки в голове. По моему опыту работы с разными заказчиками:

  • Для заказчика нормально не иметь разумных мыслей по поводу затеваемого проекта. Для многих людей в принципе не иметь разумных мыслей выходящих за рамки повседневно исполняемой работы - естественное состояние.

  • Для большинства нормальных людей - не иметь абстрактного мышления или представлениий о формальной логике является совершенно естественным. Большинство этому никогда не учили, заметное меньшинство генетически не способно этому научиться даже если захочет.

  • Если вы спрашиваете человека о возможных улучшениях, то ответ почти всегда будет в духе идеального транспортного средства в эпоху средневековья: лошадей добавить, колеса сделать повыше, золотом погуще обмазать. Гениальных Леонардо которые в ответ на вопрос могут начать рисовать вертолет - несколько штук в целое поколение.

  • Очень часто заказчики воспринимают программирование как магическое явление, которое может само по себе решать любую проблему. Несть числа я спорил с руководителями предприятий, которые требовали чтобы система не давала оформлять документы на продукцию имеющую (относительно терпимые) несоответствия (например, по весу). Они были уверены что если такой запрет сделать, то производство перестанет производить лажу. Это такой способ бегства от реальности, потому что альтернатива - это замена оборудования, изменение бизнес-процессов и прочая головная боль. Всякий раз когда такая функция была реализована, она выключалась максимум через неделю - потому что поставить клиенту продукцию не вполне соответствующую характеристикам (и, например, дать скидку) гораздо лучше чем иметь через день разъяренного клиента со вставшим техпроцессом по причине отсутствия входных деталей/сырья.

Поэтому - в первую очередь зачеркните и выбросите все, что заказчик сказал вам ДЕЛАТЬ. Вместо этого, разбирайтесь в его бизнесе - и узнавайте, какую проблему он хочет РЕШИТЬ. Я неоднократно на этом этапе объяснял менеджменту и владельцам, что они на самом деле не хотят сейчас заказывать никакое ПО. А хотят, например, заняться бизнес-процессами или элементарным выяснением между собой - какой вопрос они решают и какие цели ставят.

Дальше - предложенное в конце Time&Material - это хорошая идея для ситуации когда неопределенность высока. В проекты с Fixed price (это то самое, с ТЗ) - можно идти только тогда, когда вы уже решили 2-3 аналогичные задачи в этой сфере бизнеса, и уже имеете на руках на 90% готовое решение. В этом случае у вас конский (в разы) запас на всевозможные переделки. Играть на незнакомом поле в фикс-прайс проект с запасом 30% - лучше уж в казино сходить! Хотя бы удовольствие получите...

Что же касается ТЗ - это из серии "больше бумаги - чище задница". Вам нужно понимать критерии по которым заказчик будет оценивать успех вашего проекта. Если ваш проект успешен по критериям заказчика - вам подпишут любой акт, и не важно какие пункты ТЗ выполнены или не выполнены. Потому что альтернатива - это вы прямо завтра снимаете свою систему, и бизнес возвращается в ту точку, где он жил до начала внедрения. При правильном ведении проекта - одна мысль об этом вызывает в офисе ужас и революционные настроения одновременно. Вспомните шутку еще времен FidoNet: "К теплому туалету привыкаешь за неделю, а отвыкать обратно потом приходится всю жизнь...". Это прямое указание, как надлежит вести проекты.

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

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

Программисты не нужны, и уже довольно давно (если не считать специфических платформ, где нужно именно знать как ее, окаянную, программировать). Нужны software engineers - причем инженеры в первую очередь, а software как универсальный инструмент. Нужны люди, которые могут применять программирование для решения стоящих перед компанией бизнес-задач - которые могут понимать задачу в терминах бизнеса, предлагать решения, реализовывать их, и внедрять. Будете ли вы при этом учить программированию инженеров других специальностей, или готовить достаточно хорошо программистов чтобы они могли относительно быстро разбираться в чужих проблемах - рынку без разницы.

Помните старый анекдот: "Можно ли сделать защиту от дурака ? Да, но только от неизобретательного!". С практиками разработки - все то же самое. Мы предполагаем, что команда в целом (и каждый ее участник в отдельности) - хотят писать хороший, читаемый и надежный код. Однако, все они люди - и поэтому иногда случайно допускают ошибки. В этом смысле, наши код-ревью заменяют чтение контрольных карт в авиации. И да, разумеется, если пилот сознательно хочет чтобы двигатель встал в воздухе - никакая контрольная карта от этого не спасет.

Что делать если один из участников команды решил перейти на сторону зла и упорно пихает в кодовую базу говнокод не реагируя на замечания код-ревью? Ну, сначала - подойти поговорить. Может у человека что-то нехорошее в жизни случилось, и ему бы недельку отпуска... Не помогает - эскалировать, чтобы с ним поговорили специально обученные люди из HR и линейного менеджмента. Если же гм, индивид реально обратился ко злу и упорствует - поплакать, открыть вакансию, запустить succession process, уволить...

Я согласен, что с увеличением сложности проекта сложность тестирования тоже увеличивается, и в какой-то момент встает вопрос экономической целесообразности, и где положить конец этому процессу.

С другой стороны, это еще и вопрос архитектуры. Ну потому что если у нас есть алгоритм проверки контрольной цифры штрих-кода или расчета скидки - и мы не можем его протестировать не запуская контейнер с базой данных - это сигнал о проблемной архитектуре и early warning об огромных, невообразимых проблемах которые нас ожидают в недалеком будущем...

Я люблю математику, но вижу разницу между выпускниками матфака классического университета, и инженерами из технического.

Я согласен с тем, что тестами очень сложно проверять side-effects (такие как гонки в многопоточности). Но если мы говорим о проверке поведения кода в методе - каждый тест очевидно покрывает не только конкретный кейс, а и все эквивалентные ему по code execution paths. На практике, если мы видим что бОльшая часть (и все ожидаемые happy paths) покрыты и горят зеленым - с большой долей вероятности этот код не доставит проблем в продакшене.

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

Ну если мы видим, что группа разработчиков не осиливает современный стандарт разработки - это менеджерская проблема. И решить ее менеджерскими способами не ахти как сложно: схантить им на рынке вожака с более высоким уровнем развития, и поставить DM поумнее, чтобы бдил... Имея положительный пример перед глазами и отрицательный по жопе (кошельку), все быстро учатся!

Да, еще для этого надо верить в то, что мы несем добро. Если начать петь песню что все разработчики разные, и имеют право на жизнь все способы работы - тогда лучше да, уйти и не смотреть что там творится. Я-то до сих пор верю что цивилизация - это путь от варварства и людоедства к светлым идеалам.. :-)

Гм, религия что-ли ?! Взять сонар, и воткнуть его в гитлаб пайплайн - не запредельный уровень усилий...

Обычно когда народ начинает объяснять, что проблема сложная и не решается - это признак нежелания, а не отсутствия возможности. Дальше тимлиду или скрам-мастеру надо работать с командой, чтобы понять чего они боятся и не понимают. И устранять страхи или непонимание - в конце концов, развитие команды - как бы то, за что они (часть) зарплаты получают.

Я не люблю вот этот формально-логический подход к оценке полезности тестов. Понятно, что если 10 тестов зеленые, но мы можем потенциально написать одиннадцатый который будет красный - то код содержит ошибку. Если же подходить с практически-инженерной точки зрения, то каждый тест снижает вероятность того, что в тестируемом коде находится ошибка негативно влияющая на систему в целом. Одна ситуация, когда система падает в экзотическом случае: в четверг с 8-00 до 8-20 в четную секунду если четыре раза быстро нажать клавиши шифт и esc. Другое - когда в happy path валится NPE и все пользователи стоят на ушах. И вероятности возникновения разные, и последствия...

А алгоритмы надо (сугубое IMHO) обсуждать до имплементации (бэклог грумминг, синки, дейлики, и т.д.). Если не тот алгоритм применен - и мы видим это только на этапе MR review, то обнять и плакать - затраченные на имплементацию часы и деньги уже не вернутся...

Применяйте к линтеру простой принцип: "Устраняй или объясняй". Либо вы исправляете замечание линтера (не потому что линтер написал, а потому что вы подумали и считаете разумным это исправить). Или - напишите в одну строку комментарий и прагмой отключите в этом конкретном месте конкретное замечание, если вы не считаете его разумным.

Это не значит, что надо сесть и весь проект за один раз переделать. Кто мешает в команде договориться и ввести полиси, что в новом или измененном коде линтер должен молчать (т.е. или исправлено, или отвергнуто, объяснено и отключено) ? И постепенно кодовая база станет лучше. Причем, в первую очередь станет лучше именно активно изменяемая кодовая база.

Есть, конечно, любители отключить прагмы линтера и поставить кволити гейт в 0 предупреждений. Но тут, как говорится: дураки - единственный вид на земле которому не грозит вымирание... Если команда пишет не то, что надо - а то чем линтер доволен, мне жаль и команду и их продукт...

Information

Rating
4,213-th
Registered
Activity