Да даже с церемониями есть большой вопрос. Например когда зозвон по статусам задачь в ходе которого отслеживают что проект в диаграмме Ганта идет по намеченному плану (двигают джира тикеты по борде) — называют daily stand up. Но это вообще ничего общего не имеет с stand up-ом, и вообще с командной работой над проектом. В таком «стандапе» даже тупо молчать можно — если на тебе тикетов не за асайнено (скажем все сделал, и до релиза в беклоге больше ничего нет, за самоуправство вроде закрытие тех депта — еще и выговор схватишь).

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

По статистике во всем IT — 75% не гибкие подходы, включая FANNG-и т т.д. Если руководитель не понимает как оценивать проекты по стоимости в гибких подходах — будет галера которая для моды будет заявлять что работает по гибкой методологии. Но ходить на тренинги руководству самим в западло и они поэтому посылают туда: программистов, аналистов и тестировщиков — а потом в работе все равно все по старому. Надо ещё учесть что половина — вообще не планирует работу даже через диаграмму Ганта. Просто есть распорядка — " закончить к Декабрю до Черной Пятницы«. И погонщики плетьми будут гнать всех в шею и овертаймы, даже если такой объем физически выполнить текущими силами невозможно. А под конец ещё и увеличат команду в двое понимая что никак не успеть. А тут вдруг «закон Брукса» ... В общем это уже к топику про «некомпетентность в ИТ».

В общем результаты опросов которые провели авторы только подтверждают результаты исследований которые провели NASA. Пытаясь понять почему введение agile не приносит результата в большой части команд, тогда как в других напротив к внушительные результаты — выяснилось что в тех командах где результата нет — никакого agile тоже нет. Там только декларируется что есть гибкие методологии — а на самом деле другие процессы, как правило бюрократические с откровенной тиранией. В итоге это назвали Fragile (липовый agile) также известен термин ScrumBan или Срам. По итогу ввели методику оценки проектов чтобы отделять настоящие гибкие методологии от фальшивки habr.com/ru/post/436866 и
Из моей практики большая часть команд «работающих по Scrum» — в лучшем случае работают по водопадному подходу с диаграммой Ганта. А как правило вообще по «ляп ляп и в продакшн». Причем изменить процесс может фактически только профессионалы из специальных организаций или отделов вроде PMO. Причем смысла работать с рядовыми исполнителями сразу нет — на гибкие методологии должно пойти начальство. Иначе толку не будет никакого.

«Жирный» заказ/подряд — совсем не обязательно принесет прибыль. Очень даже может быть что наоборот — убытки, ещё и все нервы выпьет. Как раз и держат бенчи поэтому те кто может себе это позволить — чтобы не попасть на бабки рекрутируя непосредственно перед подписанием контракта.

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

Насправді пробіл в три місяці нікого не цікавить. Якщо ви у випробувальний період не робили нічого цікавого — що буде корисним для вашого резюме, просто нічого не пишіть і все. Все що ви там напишете — це привід задати про це додаткове питання на співбесіді.

Взагалі круто. Але є midnight commander, чому саме ця тема ? От кольорових du та df які одразу видають людський вивід замість скріптового — нема.

Різне буває. І клієнти які на три місяці, і стрибуни на три місяці.

• Голова которой думать
• Руки которыми делать
• Попа на которой сидеть
• Туловище которым переваривать хачи для работы головы
• Компьютер с выходом в интернет

Умный директор был. К сожалению ситуация классическая.

В большинстве хитрых комбинаций — жертвуют ферзем, тем самым загоняют оппонента в ловушку и ставят мат.

Что тогда дело для менеджеров ? Малевать презентации для митапа с надписями «Very important» ?

Есть куча контор где по два три проекта на людях висит. Причем годами не увольняются — пришли джунами и не знают что бывает по-другому.

Закроют позиции без проблем. Подберут правильных собеседующих и т.д. Однако Фредерик Брукс в «мифический человеко месяц» — назвал этот метод «тушить пожар бензином». Получите половину штата новичков которым надо найти: место, оборудование, заонбордить и пройти стажировку. Поэтому менеджмент их посадит ворон считать в окне чтобы не отвлекать команду пока она проекты допиливает в овертаймы. Новички в отместку будут снимать видосы где тетрадку к клавиатуре «подключают» за неимением ничего другого к чему ее можно подключить и лысый тимлид в свитере пчёлки бегает на цыпочках между джуниорами.

Если работников найти легче зачем платить HR-ам с бонусами ? У кого то HR процесс сильный в конторе, у кого то Sales of Marketing. В общем — аргуметов в реплике не вижу.

Ок. По базовым правилам философии перед ведением дискуссии нужно определиться с понятиями перед ее началом. В Русском языке слово клиент — можно трактовать и как разового покупателя или заказчика работ/услуги, так и лицо заключившего постоянный договор. В английском есть customer и client. Скажем у продавцов в магазине или парикмахеров — есть customer т.е. каждый раз заключается новая сделка, а у адвокатов или брокеров — clients т.е. сделка заключается один раз на определенный срок и наступают взаимные обязательства.

Бывает так что клиент вообще убыток приносит

может быть и в случае customer (бывают window shopper, и ситуации когда конкуренты маскируются под клиентов и саботируют работу выдают фразы вроде «вы не программисты — а воры», «мы провели исследования и считаем что ваш продукт хуже чем [главный конкурент] и должны вас в этом проинформировать», ну и в том же духе) и в случае client (со мной было два раза когда попали в убытки чтобы выполнить обязательства, при этом в обоих случаях клиент наотрез отказался платить за менеджеров и QA, но уволенные в последствие сейлы все равно подписали контракт — и синьйорная команда по завершению разошлась кто куда).

На докер посмотри. Под виндой особенно проблемы аналогичные. Очевидно что это закономерность — как эффективно писать код на C++ многие уже хорошо знают. Есть куча книг от Александреску, Маерса, Саттера и т.д. Типичные проблемы D, Go, Rust анти паттерны и бест практики ещё предстоит выявить. Хотя ИМХО FireFox стал в разы лучше после создания нового движка, но это связанно не с языком программирования — а с тем что его написали заново и выкинули все деприкейшены. Gecko написанный на C++ представлял из себя свалку кода миллиардом макросов. Вот где текла память по настоящему, особенно через плагин API.

Ну Excel тоже отдельная тема про Джоэла Спольски. Тоже серийный попадатель в точку.

Ну тут аудитория которой на это с колокольни в массе своей. Это на другом ресурсе тусуются. Тут про работу в основном, зарплаты, переходы, трактора и т.п.