Comments 11
1. Смысл всякой деятельности лежит вне её пределов
Это хорошо сказано, но пример все портит. Потому что, предположим, 9999 не нужно никому, команда просто привыкла хорошо писать код. Что делать? «В следующий раз пишите хуже»? Будет ли хуже=быстрее? А если и быстрее было ни к чему?
По мне, хороший пример: разработкой движет не прибыль от программного продукта, а привлечение инвестора. Или сокрытие основного вида деятельности — типа как «Компания по разработке 1С решений» имеет налоговые льготы. А основная деятельность — заправка картриджей и установка винды (но по бумагам — это «сопровождение инфраструктуры 1С»).
2. Чтобы придать смысл деятельности, можно поставить ей цель.
Но дальше по тексту написано, что у команды уже есть цель. Вне пределов, так сказать.
3. Каждого исполнителя нанятой команды нужно «знать в лицо»
Полная чушь.
Предположим, у разраба А есть потребность в устройстве ребенка в детсад, а у разраба Б — в размещении проекта в Azure.
Маленькая компания может влезть в личную жизнь всех разрабов (было бы желание), но дать-то сможет только деньги.
Большая, очевидно, всех в лицо не узнает никогда. Но, в принципе, может предложить и корпоративный детсад, и участие в проекте на Azure.
Вот вам реальное приложение этого примера.
Есть деталь, на детали есть отверстие, которое вытаскивает автомат под руководством оператора. На чертеже указано, что размер — 30 ±0.005мм. Это довольно жёсткий допуск. Оператор вынужден измерять каждую деталь и вносить поправку на износ инструмента. Если не не внести поправку два раза, из-за износа отверстие окажется меньше, чем допустимо. Приходит технолог, смотрит на это всё, уходит, возвращается с новым чертежом, выяснив, что такой жёсткий допуск — ошибка, для функционирования детали достаточно допуска ±0.012мм. Оператор теперь может внести поправку заранее с запасом и четыре раза не вносить её, экономя как свое время (которое может тратить на что-то ещё), так и время простоя автомата (потому что поправки во время работы не вносятся).
Это не значит, что детали стали "хуже", это значит, что оператор перестал делать их точнее, чем нужно, тратя на это время. При этом, естественно, критерий качества результата обязан быть адекватным, а не от балды.
Но автор внес поправки в текст и теперь пример выглядит еще глупее:
Смысл всякой деятельности лежит вне её пределов
надо разобраться, кто главный потребитель такой стабильности и насколько он ей доволен
Выходит, смысл деятельности любой компании по-умолчанию не в извлечении прибыли путем удовлетворения клиента.
Вывод: смысл примера автора лежит вне пределов формулировки теоретического посыла и разобраться в причине он не может.
Большая, очевидно, всех в лицо не узнает никогда. Но, в принципе, может предложить и корпоративный детсад, и участие в проекте на Azure.
Касательно Azure, как правило, наоборот.
В маленькой могут сказать, мол, ок, раз твой азур решит наши проблемы, то давай, собери РоС на free tier или триальных кредитах, потом глянем, и если тема хорошая, то заведем и проплатим акк с личной карты фаундера)
В большой, если азур не предусмотрен немногочисленной группой людей, имеющей монополию думать и решать, то никто заводить аккаунт в азур, подписывать NDA с майкрософтом, и создавать и утверждать политики безопасности по работе с азуром не будет ради перспективного девелопера, который хочет и видит в этом ценность. Максимум, скажут, на +$250 к зп, и на выходных тебе никто баловаться азуром не запрещает
К тому же, описанный вами случай не совсем подходит под
понимать обстоятельства его личной жизни (ради чего он вообще пошёл на работу)
То есть, если разраб имеет вИдение и может обосновать необходимость, то это не подпадает под «личную жизнь» и «узнать в лицо», это его хард-скил.
А вот в качестве «узнать в лицо» это что-то, типа хочу попробовать прыгнуть с парашюта и реализовать проект в Azure.
(Но касательно хард-скилов, я считаю, что все примерно наоборот в больших и маленьких компаниях.)
предположим, 9999 не нужно никому, команда просто привыкла хорошо писать код. Что делать?
Передать задачу другой более дешевой команде, например. А для рок-звёзд найти более подходящую задачу. Сова должна придумывать новые методики управления!
Но, видимо, автор догадался, что это выглядит как-то не оч. Поэтому отредактировал:
если команда обеспечивает стабилизацию продукта до трёх девяток, надо разобраться, кто главный потребитель такой стабильности и насколько он ей доволен.
И превзошел себя. Оказывается, если команда выполняет какую-то задачу по проекту, то нужно обязательно разобраться есть ли это в ТЗ, и доволен ли заказчик. Запомните, дети, обязательно. (Хоть это и лежит вне пределов деятельности компании, естественно.)
Или руководитель компании? «Просто не терплю говнокод.»
Или регулятор? «Я, как клиент, хотел бы подешевле, если у регулятора печать поставите, то мне вообще аптайм не нужен.» (Обычно, связано с покупкой/доработкой ПО, «согласно ГОСТа» для получения сертификата соответствия.)
Есть ли тут вообще что выяснять? Есть ли хоть одна компания, которой такие кейсы не очевидны (клиент, который платит, не является заказчиком определенной фичи, но без нее не обойтись)? Детский сад.
Вы это кому пишите? PM'ам или линейному персоналу? Линейному персоналу бизнес-задачи могут быть интересны, но в область профессиональных интересов не входят. А вот повышение личной (и команды) продуктивности — входит.
Так что лучше пойти и написать тесты, и поискать метод для ускорения их запуска.
Не могли бы привести определение.
Неясно, о чем разговор.
Осмысленность работы и эффективность