Speed in software development

Every single CEO of any IT company wants to build software faster. Time is the most expensive and valuable resource. You can’t waste it on re-work, refactoring, meetings, physical activities. Right? It depends...

www.targetprocess.com/...​software-development.html

Про інтенсивність, скіли і досвід, заохочення до навчання, необхідність розуміння домену девелоперами, Technical Debt, дедлайи, овертайми, потік і багато іншого в одній статті лаконічно і зрозуміло

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Хорошая и правильная статья. К сожалению, для нашего ИТ она слишком «чужая».
Ее главная идея очевидна: это баланс между скоростью и перспективой. Скорость (и прибыль) сегодня — это замедление (и потери) потом.
Я бы сказал, что она подходит компании, похожей на футбольный клуб. Где команда — это главная ценность. И цель которой — именно многолетнее развитие и достижение новых вершин, а не профит прямо сегодня. Поэтому позволить себе такую стратегию развития могут только богатые компании.
В наших реалиях никто не готов вкладывать а компанию, которая через 10 лет станет «чемпионом» (разве что Ахметов продаст Шахтер и купит ИТ). Всем нужны компании, которые эти 10 лет будут стабильно приносить 10 — 20% прибыли. А это значит: вместо «марафона» и развития — «потогонка» и «вытряси и выброси».

А мне понравилась статья, спасибо, Тарас.
Лично я согласен с тем, что хорошее ПО создается только при марафоне. Однако нашим PM-ам и прочим «нащальнике» вы это не докажете и вас выставят еретиком и противником идеологии Sprint-ов, а также припишут все, что угодно сверху.
Вот причины почему это у нас не приживется:

1) слабые отечественные управленцы нормально спланировать ход разработки — сложная, нетривиальная и неповторяющаяся задача. В сертификации PMP существует модель «конус неопределенности» на разрабатываемый проект. Иными словами чем дальше дедлайн, тем больше рисков и нужно учитывать стадии разработки. Большинство бывших QA-ев, ставших PM-ами за непонятные заслуги, неспособны мыслить на такой далекий промежуток времени, строить модели и считать риски. Они предпочитают беседы как замены всему.

2) отечественная всеобщая расхлябанность и лень, дающая цепную реакцию во все сферы. С утра вызвал такси — не приехало. В магазине стоял 40 мин в очереди на кассу — опоздал на работу. Получил втык от PM-а за опоздание — оторвался на коде / коллегах и пошло поехало.

3) бюрократия и торможениесуществует во всех наших компаниях, когда люди цепляются за прошлое непонятно зачем. Иными словами даже если все остальные факторы
будут устранены, то «аврал», «пятилетку за 3 года» и прочие стахановские замашки практически невозможно вывести из подсознания или (если вы в это верите) генетической памяти.
Из недостатков слижком сложная схема:
www.targetprocess.com/.../speed/map2.jpg
концовка смазана и дальше осознавать уже тяжело.

Выводы: идея хорошая, но у нас она не приживется.
В бодишопах — по причине низкого качества кадров, бюрократии и направленности на часы.
В продуктовых — про причине низкого качества управленцев (таких же как в бодишопах).

Ну почему же не сработает. Естественный отбор со временем все расставит на свои места. Подготовленные и быстрые выживут, медленные — помрут.

Менеджерская чушь в стиле «гладко на бумаге». Годится чтобы выступить на конференции «Узрите, как мы круты». Сборная солянка копипасты красивых слов, не понимая о чём они и как работают технологии.

Я считаю, нет большего зла, чем допускать в верхнее и среднее руководство людей, которые не имеют опыт:
— непосредственной работы [не-начальником],
— непосредственного руководства над не-начальником.

Это всё равно что ставить тренером футбольной команды — букмекера. А букмекером — болельщика из бара. Хотя и тот и другой могут написать прекрасные книги о футболе. Только не стоит их книги считать полезыми — это лишь развлектательное чтиво, не более.

точно читав? бо я побачив трохи інші речі, імхо, це якраз не стаття-маструбація на всякі еджайли, а опис проблем, які виникають від гамноменеджементу (нафіг рефакторинги, дайош овертайми, getting shit done, фічі — наше все, кинули каву і пішли нах писати код і тд).

ідея — швидкість розробки продукту залежить від багатьох факторів, про які більшість менеджерів зовсім не думають

Точно читал. И читал об этом куда более грамотные тексты.
Здесь автор ушёл с головой в идею, что есть 100 500 миллионов факторов, которые “нужно учитывать” [то есть об этом пагаварить], и нихрена с ними не сделаешь — настолько огромна и неподъёмна проблема в целом. Потому делайте как делали, а через 20 лет будем жить при коммунизме.

Как сказал бы “прибулець Павло” — Ви ж тупі як срака, чого вас вивчати.
И здесь я вынужден с ним согласиться. Фундаментом этих отношений являются люди. Самые обыкновенные, у которых практически всё одинаково и лишь чуть-чуть различаются. И трудовые отношения что для разработки программ, что для выращивания картошки — схожи на 99.* процентов.

Можно сколько угодно рассуждать о командном духе, о форме зданий, и рисовать заоблачные мега-схемы организационных коммуникаций. Есть лишь маленькая загвоздка: ничего из этого не существует в природе, либо не влияет на трудовые отношения. А влияют самые обычные отношения людей — двусторонние и трёхсторонние. Всё! Это грёбаный базис. Из которого можно построить хоть компанию алкашей, хоть мега-корпорацию.

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

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

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

И первое что делает “мэныджыр” — это устраняет систему ПРЯМОЙ обратной связи, заменяя генератором хороших отчётов. Как только обратная связь исчезла — организация фактически становится наркоманом хороших новостей. Оплачивая только тех, кто приносит хорошие новости. С предсказуемым концом.

Сказку может читать кто угодно, но применять — зась!

Красиво написано!

>

Потому делайте как делали, а через 20 лет будем жить при коммунизме.

Интересно бы посмотреть на место в статье, где это говорится хотя бы косвенно. Я крайне удивлен, что статья вызывает такие ощущения.

думаю тебе должен нравится японский стиль менеджмента

Да. И китайский. Мне откровенно нравится их система организации производства. Им не нужно 2 начальников на 1 работника.

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

не понимая о чём они и как работают технологии

Какое смелое утверждение :) Давай что ли какие-нибудь верифицируемые аргументы, а не красивые общие фразы.

очень интересная статья, хороший анализ того что влияет на разработку

Я б трохи посперечався про

If refactoring is so good, can we refactor all the time? Definitely not. Refactoring is a non-value added activity. You are not adding any business value when you refactor the system. You reduce complexity, pay technical debt back — yes, but customers gain nothing. Business value is generated by new code.
Звісно, не можна перебувати в стані перманентного рефакторингу. Але в процессі рефакторингу зменшуються витрати на підтримку та додавання нових фіч, також можливе підвищення стабільності та скорості роботи, що все ж таки може коштувати грошей: чим швидше та стабільніше працює ПЗ, тим легше його експлуатувати, тим еффективніше в ньому працюють користувачі.
Я вважаю, що треба це пояснювати замовникам та керівництву.

так там вообщето и описывается что это уменьшает технический долг, с пояснением когда его наличие нормально а когда нет, и соотвественно когда реально нужен рефакторинг

я не зрозумів з чим саме ти не згоден,

Could we write perfect code and create perfect solutions with a single shot? I wish we could. But we can’t. Moreover, requirements change and initial decisions no longer fit. That’s why we have to iterate and refactor.

поінт автора тільки в тому, що не можна рефакторити заради рефакторингу (типовий школотизм)

Я про те, що іноді можна (і треба) «продати» рефактиринг клієнту.
Наприклад: якщо глянути на нашу банківську сферу, то, з точки зору кінцевого клієнта, там рефакторинг — необхідний.

Подписаться на комментарии