Ох уж эти программисты

PHP, Golang, Python? Angular, Vue, React? Этот вопрос мне периодически задают основатели молодых компаний, размышляя, на каком стеке писать первую версию своего продукта. И знаете, каждый раз я отвечаю примерно одно и то же: это не важно. Почему? Потому что на самом деле есть только один критерий — берите то, что проще, дешевле и доступнее прямо сейчас. Ваш выбор должен основываться на том, кто у вас есть в команде, какие технологии вы знаете сами и кого вы можете нанять за адекватные деньги. Всё...

— Мы пилим монолит на микросервисы! Часто слышу я от молодых компаний, которые консультирую. — А зачем? — уточняю я. Дальше следуют ответы: Правильного ответа, как обычно, не существует. Мне близка точка зрения Криса Ричардсона, с которым я имел честь несколько раз пообедать. Крис — известный эксперт в разработке, специализируется на архитектуре микросервисов, пишет книги на эту тему, много публикует и выступает. Он создал ресурс microservices.io, где собраны ценные материалы по этой архитектуре...

Довелось мне сотрудничать с достаточно консервативной компанией, которая существует на рынке не один десяток лет, и сотрудники в ней работают по 5-10-15 лет к ряду. При внедрении изменений регулярно сталкивался с инертностью команды, которой не очень-то хотелось менять и меняться. Реакция на предлагаемые изменения звучали примерно так: — Скрам? Мы его внедряли много лет назад, он у нас не работает. — Фича-команды? Мы уже пробовали такую структуру, нам она не подходит. — Юнит-тесты? Да, мы как-то начинали их писать, не понравилось и больше не хотим...

Представьте себе, что перед вашей командой стоит задача, от которой зависит выполнение целей бизнеса. Новый функционал должен принести компании дополнительную прибыль. Всё на кону: амбициозные цели, высокие ожидания и надежды бизнеса. Но, несмотря на все усилия, спустя месяцы работы проект всё ещё далек от завершения. Так началась наша история. Она о том, как мы кратно увеличили скорость работы команды, не увеличивая её бюджет. Когда проект начался, всё выглядело логично и организованно: Бизнес-заказчик...

— Технологическая стратегия не нужна. Такой ответ я услышал от кандидата на руководящую позицию, когда спросил: "Зачем компаниям нужна тех.стратегия?". С такой позицией я категорически не согласен. ИТ-затраты — это весомая статья расходов для большинства компаний. Фонд оплаты труда специалистов, оборудование, лицензии, SaaS — всё это требует серьёзных вложений. И не секрет, что часто эти вложения не оправдываются: проекты затягиваются и не приносят дохода, технический долг тормозит развитие продукта, утечки данных подрывают репутацию, а команды раздувают и работают неэффективно, сжигая бюджет. Тех...

Этот вопрос — один из моих любимых на собеседованиях с кандидатами на руководящие должности. Он помогает мне лучше понять самого человека, избежав социально ожидаемых ответов. Ответив на него, кандидат фактически рассказывает о себе, а не о других: о своих ценностях, убеждениях и мотивации. ✦ "Люди переходят в менеджмент, чтобы влиять на решения и развитие компании" — этот ответ говорит о высоких амбициях и стремлении к большему влиянию. ✦ "Желание помочь людям расти, раскрывать потенциал команды" — показывает, что кандидат ценит развитие других, готов быть наставником, заботится о сотрудниках...

— Нам нужно выплачивать тех.долг! — У нас нет на это ресурсов, нам нужно выпустить новую фичу! Знакомый диалог? Давайте поговорим про технический долг и про то, как он влияет на бизнесовые цели. И на выпуск новых фичей Вот определение от chatgpt Технический долг — это неизбежная часть разработки любого программного обеспечения. Он возникает, когда команда принимает решение обойтись временным решением или сознательно упрощает реализацию, чтобы быстрее выпустить функциональность. Но, как и финансовый...