Как стать автором
Поиск
Написать публикацию
Обновить

Когда «ускорить разработку» — значит всё сломать

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров1.9K
Всего голосов 5: ↑5 и ↓0+6
Комментарии4

Комментарии 4

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

Универсальность советов зачастую прямо соответствует их банальности, а полезности — обратно. Лично мое мнение: проблема не уникальна конкретно для айти; на темп влияет больше всего не некая "инженерная зрелость" отдельных членов (не важно, сколь многочисленных), а навыки и возможности менеджмента и руководства. Если исправление "любых мелочей" является частым и тратящим заметное время явлением, вопрос больше не к инфраструктуре, скорее к компетенциям ответственных и процессам в целом (отсутствует должный контроль качества).

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

Когда идея о некоей разумной оптимизации трат лежит в основании рабочих процессов, тогда и до всего остального со временем получается добраться. И до повышения компетенций (зная, каких, у кого, как именно), и до улучшений окружения (зачем, как, когда), и до ускорения выполнения типовых работ — при необходимости в том числе за счёт привлечения дополнительных ресурсов.

Полностью согласен с тем, что темп определяется множеством факторов, и инженерная зрелость — лишь часть картины. Именно поэтому я и старался в статье подсветить один из самых недооценённых аспектов, который часто упускается в малых командах и на ранних этапах проектов — где архитекторов и продвинутого менеджмента просто нет.

Безусловно, зрелое управление, контроль ресурсов, культура постоянного улучшения — всё это критически важно. Но если при этом разработка разворачивается вручную, баги ловятся "на проде", а каждая задача начинается с “а где у нас это вообще лежит”, то даже сильное управление будет буксовать.

Вы правы, что это не только про IT. Но в IT потери из-за инфраструктурной сырости особенно заметны, потому что стоимость итерации часто минимальна — и значит, каждый тормоз бьёт по скорости сразу.

Очень классный комментарий, возможно, стоит сделать об этом отдельный пост: как сочетаются инженерная зрелость и зрелость процессов управления.

У прошлого аккаунта слили карму? Высказывания в статье достаточно категоричны

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации