Делать как для себя

Редко, когда разработка железа, ПО, да и любая работа, идет не в команде. Разработчиков отшельников в расчет не берем. 😋 А где команда, там появляются цепочки процессов. Не важно описанные они или образовались и зафиксировались естественным путем. Но стоит помнить о том, что же будет дальше с результатами труда каждого участника? Подкреплю примерами из жизни.

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

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

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

Либо совсем элементарный пример. Принимает кто-то ценный груз, но коробку после вскрытия запаковывает кое-как. Следующий взявший ее со склада, не зная подвоха с непроклеенным дном, разумеется, уронит и повредит товар.

Эти примеры всего лишь из внутренних процессов. Когда что-то уходит за пределы команды вариации возрастают.

Думаю, всегда стоит подумать:
⚽️ Кто стоит следующий в цепочке действий?
🏀 Хватает ли ему знаний о том, что было сделано?
🏐 Как облегчить ему работу?
🏉 Как бы я хотел, чтобы мне передали задачу?

Классно замечать, как люди учатся на своих и чужих ошибка и постепенно начинают относиться к делам вдумчиво.

@aheadofthepack