Я несколько о другом. В командной работе выделяют разные роли (генератор идей, зануда и т.п., их много и классификаций тоже много).
Главное - люди, как правило, имеют хорошие способности только к части этих ролей, а в других будут в лучшем случае посредственны. По сути, некоторые из них требуют противоположных личных качеств.
Для эффективной работы команде требуются носители всех или большинства ролей. Но роли и позиции в команде в общем случае не совпадают.
Собираясь в команды, люди занимают определённые должности и принимают на себя определённые роли.
Для того, чтобы закрепить в процессах подобные практики, нужно подбирать на определённые должности людей, способных эффективно брать на себя определённые роли. К сожалению, это далеко не всегда и далеко не везде возможно.
В каждой команде, безусловно, должен быть человек, исполняющий роль Критика, который критически разбирает любую идею, проверяя её на слабые места. Безусловно, такой человек должен быть ориентирован на результат, а не на процесс, и быть глубоко погружённым в пользовательские сценарии, иначе его критика не будет конструктивной.
Эта роль идеально сочетается с позицией QA. Увы, не всегда и не всем удаётся найти именно такого человека, сочетающего соответствующие компетенции с соответствующим образом мысли и интеллектом.
Собственно примерно поэтому, строго говоря, 3 Amigo это история про трёх друзей, а не про PM, Dev и QA. Если этот момент игнорировать (просто станьте ёжиками, мышки), то получается очередной (100 500) случай процесса, который мешает достигать результата, а не помогает это сделать.
Вообще-то, Канбан это куда больше и сложнее, чем просто "берём приоритетные задачи с доски", это нулевой уровень зрелости, так сказать. По сути, он и есть "скрам без спринтов", с соответствующими ритуалами даже.
Просто планирование работ осуществляется для отдельной стори, а не по принципу "нужно полностью набить спринт", а периодичность глобальных ритуалов, типа ретро, выбирается исходя из разумности и необходимости, а не искусственно прибивается гвоздями к спринту.
Впрочем, скрам тоже в последние годы стал более разумным, впитав некоторые идеи Канбана (цель спринта, к примеру).
Если что-то делать через задницу, то и результат закономерно выйдет из этого самого места.
Хотя про методологию расчёта "коэффициента участия" я бы с удовольствием послушал в деталях. Конечно, только при условии, что это не было полной шляпой, как это обычно бывает.
Тем не менее, сейчас ситуация в индустрии откровенно нездоровая:
вклад сотрудников в конечный результат может очевидно различаться в разы, а оклад при этом различается на десятки процентов
член команды может иметь околонулевую полезность для достижения результата, но его будут терпеть месяцами или даже годами, так как те, кто это видят и понимают, не имеют личной заинтересованности в сокращении издержек проекта в целом
бизнес заинтересован исключительно в рентабельности продукта, в то время, как исполнители практически не имеют такой заинтересованности и не мотивированы в её достижении
Результат в конечном итоге не идёт на пользу никому, а значит, ситуацию можно и нужно менять.
Менять её бизнес пытается с помощью глубоко формальных критериев (KPI), что приводит к фальсификации результата, а не достижению целей. Кроме того, бизнес пытается снизить издержки, удерживая себестоимость управляющих сигналов (читай - премиальных) как можно ниже, что обесценивает эти самые сигналы. Что мне эти ваши 10% годового дохода? Для меня это совершенно не принципиально, это не ключевой фактор принятия решений.
IT-шники, в свою очередь, не хотят понимать, насколько IT-проекты - дорогое и рискованное мероприятие. Окупаемость не просто не гарантирована - она достаточно маловероятна. Поэтому аргументация в духе "а пусть просто платят больше" - нифига не конструктивна.
Поэтому я вижу только один вариант - смещение крупного бизнеса в IT в сторону стартапной модели, где рядовые исполнители частично разделяют с основателем риски своего проекта, но при этом рассчитывают на кратное увеличение дохода в случае успеха. Да, на этой дороге тоже будет много боли, но таков путь.
Ну, лет 20 тому назад работал я в славной компании Крок. Во вполне себе "российских условиях". И была там тогда забавная фишка - Лид команды (в тогдашних терминах компании - "Программ Менеджер") получал именно процент от прибыли проекта, которым занимался.
Это порой приводило к забавным коллизиям... но в целом - работало. Причём стать этим самым ПМ-ом было на удивление просто. Всего-то и требовалось - продемонстрировать минимальный эмоциональный интеллект и ориентированность на результат, а не на процесс и IT-шную крутость.
Про опционы рассказывать же не нужно, все и так знают? Обычная практика.
Так что нет, многие руководители и владельцы бизнеса с радостью разделят с сотрудниками прибыль при условии их готовности разделять риски.
Но вы упёрлись в глубоко третьестепенный вопрос. Главное-то другое - право команды самим перераспределять свой бюджет, никого особо не спрашивая (в разумных пределах). Но - с ответственностью за конечный результат и никак иначе.
Мы никогда не знаем, сколько времени займёт решение поставленной задачи. Но мы имеем достаточно неплохое интуитивное представление о том, насколько сложной кажется эта задача судя по её описанию и исходя из практического опыта.
Почему, имея неплохое представление о сложности задачи, мы не можем назвать срок её решения?
А вы откройте ваш трекер и посмотрите, сколько времени НА САМОМ ДЕЛЕ занимало решение задач, изначально оцененных в N попугаев, где N - любое число, не сводящееся в конечном итоге к одному-двум часам. Что вы получите на выходе, неужели цифру? А вот и нет, вы получите диапазон цифр, примерно соответствующий нормальному распределению.
Это по факту будет так, а факты - очень упрямая вещь. Вот и скажите мне - как, прекрасно зная это, вы можете продолжать требовать в качестве ответа ЦИФРУ? Какую именно, блин, цифру? Среднюю? Девяностопроцентный персенталь? Девяностодевятипроцентный персенталь?
И почему вы вообще требуете эту цифру от технических специалистов-то? У Project Manager-а доступа к Jira нет, он сам получить нормальное распределение не может? А ведь это самое распределение и есть - единственно возможный, честный и точный ответ. Всё остальное - ложь.
И для чего эта цифра вообще нужна? Для какого такого планирования? Планирования по одной задаче? А зачем такое планирование нужно-то? Планировать нужно не одну отдельно взятую задачу, а scope этих самых задач. И вот именно для такого планирования вам и нужно честное распределение вероятностей, а не взятые с потолка субъективные цифры сомнительного качества. Потому что именно по такому, качественному набору данных, вы и можете построить свой реальный план с любой требуемой в вашем случае точностью (иными словами - с допустимым в вашем конкретном случае риском срыва планов).
Была раньше такая замечательная передача "Grand designs" про строительство нестандартных домов.
Общий вывод из просмотренных двух сезонов - все сроки и все сметы нужно умножать на 2. В смысле - полная глупость этого не делать, даже при том, что всё было просчитано профессионалами высокого класса.
Там ещё была типовая шутка "будет готово к Рождеству". В смысле - без уточнения года.
ага, бедная, отсталая рассия-матушка, где всё не так, как на прекрасном, цветущем западе, как же без этого :)
В принципе - не вопрос, но тогда эффективные программисты, конечно, тоже не откажутся внести свою лепту и согласятся перераспределить свои зарплаты таким образом, чтобы большая их часть была привязана к коммерческому успеху продукта? Практика, так-то, достаточно распространённая, но не в наших широтах.
Впрочем, тут вообще многое перебалансировать придётся, изменение отнюдь не косметическое.
Отношение к людям, как к ресурсу, характерное как для руководителей среднего звена и выше, так и для HR, как системы, оно в принципе не про эффективность. Т.е. хотите эффективности - так работать нельзя, нужен индивидуальный подход.
А индивидуальный подход, в свою очередь, он не про масштабируемость. По определению. Поэтому работает он только в маленьких коллективах.
С другой стороны, индустрия IT для работы над проектами, в том числе и масштабными, вынуждена изобретать интересные, нестандартные, подходы. Кроссфункциональные команды, agile, относительное равноправие бизнеса и технических специалистов в принятии решений.
Мне кажется, что будущее в адаптации IT-бизнеса к этому подходу с превращением как минимум продуктовых команд в условно-независимые бизнес-юниты со своим собственным бюджетом. Вася хочет повышения зарплаты? Не вопрос, какие статьи расходов нашей команды мы режем, чтобы это обеспечить?
Можно всем срезать премии. Можно уволить Колю, толку от него так-то не особо много и всяко меньше, чем от Васи. Можно сократить расходы на командную площадку в облаке, отказаться от одного из стендов и уменьшить период хранения логов до трёх дней.
Можно увеличить выручку продукта, тогда зарплату можно будет поднять не только Васе, но тогда Васе придётся подождать несколько месяцев, а результат не гарантирован.
Можно попытаться поднять цену владения командой и продуктом для материнской компании, переложив на неё издержки. Может прокатить.
А может, Федя вызовется делать работу Васи за 2/3 его зарплаты и можно просто помахать Васе платочком на прощание с наилучшими пожеланиями.
Было бы здорово, если вы могли бы раскрыть больше деталей про маршрутизацию на местности, объезд препятствий и избегание столкновений/пересечений с другим транспортом и пешеходами на местности, но и так спасибо за интересный материал.
Правда, лично у меня остался вопрос - такие роботы стоят очень и очень недёшево. При этом он может перемещаться, но не может быть в двух местах одновременно.
Установить стационарно полсотни таких вот газовых анализаторов и несколько десятков вебкамер в ключевых местах не дешевле вышло бы? А даже если нет, не надёжнее ли?
Мне кажется, что реальный объём полезной работы, которую я могу проделать в течение рабочего дня / рабочей недели слабо связан с собственно рабочим временем. Это вопрос управления энергией, а не временем, по большей части (понятно, что пары часов в день категорически недостаточно, а вот насчёт четырёх часов я уже не вполне уверен, насчёт шести - уверен полностью).
Полагаю, я бы согласился на некоторое снижение зарплаты в обмен на дополнительный выходной. Возможно, даже на пропорциональное. Потому что интегральное качество жизни от этого только повысилось бы, мы же буквально размениваем отпущенное нам время жизни на деньги, но зачем нам деньги взамен жизни, если времени пожить не остаётся?
Сотрудники на удалёнке (с минимальным контролем) и фрилансеры, в принципе, в той или иной степени воплощают этот принцип без всяких глобальных национальных правил. Но это требует высокой самодисциплины, причём в обе стороны.
Разумеется, если бы моя работа заключалась в том, чтобы упаковывать в коробки товары с проезжающей мимо меня ленты, то приносимая мною польза была бы прямо пропорциональна рабочему времени и пункты №1 и №3 не имели бы никакого смысла. В отличие от пункта №2.
Тут как-то неявно предлагается, что в раннем ЦРУ работали мрачные серьёзные гении, скрупулёзно проработавшие теорию организации саботажа на рабочем месте.
Но с таким же успехом эту брошюру могли составить пара саркастичных мужиков, вроде нас, с опытом работы в крупных корпорациях, у которых подгорело.
Поэтому все случайные совпадения - ни разу не случайны.
Техлид — это разработчик, который первым осваивает новые технологии до уровня, достаточного для перевода на них основных проектов
Возможно, в вашей компании всё так и есть. Но я вот не согласен с таким определением - на мой взгляд, это определение ведущего разработчика, они для этого и нужны.
Больше того - нет никаких причин, по которым таких "техлидов" в команде не могло бы быть несколько. И даже больше того - в кроссфункциональной команде их и должно быть несколько (в общем случае).
Но так как единого ГОСТ-а с определениями нет, то каждая компания вправе изобретать свои собственные определения и наполнять их своим смыслом. И всё бы ничего, но при переходе из компании в компанию такие штуки порождают множество wtf-ов с обеих сторон. :)
В целом, основная проблема рассуждений про обязанности лидов - в крайне расплывчатой формулировке этого понятия, которое очень сильно различается от компании к компании.
К примеру - есть два созвучных термина, ТимЛид и ТехЛид. Это одно и то же или это разные вещи? Большинство компаний просто выбирают один из этих терминов и не парятся по поводу деталей. Сама же идея того, что команде нужен технический руководитель, мягко выражаясь, не нова, вот и берётся современный термин для старой, как IT, концепции.
Лучше всего, в теории, на этот вопрос могли бы ответить компании, которые в штатном расписании имеют и тех и других. Я знаю две таких компании.
В первой команды разрослись до неприличных размеров и их реорганизовали, добавив дополнительный уровень иерархии. "Большую" команду возглавляет ТимЛид, а "маленькие", из которых состоит "большая", возглавляет "техлид". Но с таким же успехом можно было бы объявить "большую" команду - "отделом" или "направлением", которую возглавляет "руководитель направления", это было бы даже честнее.
Во второй компании использовали post-spotify матричную модель, в которой ТимЛиды возглавляли команды, а ТехЛиды - технические направления (backend, frontend, devops и т.п.). Эти товарищи просто использовали термин "ТехЛид" для обозначения относительно новой роли, которую правильнее было обозвать "лидерами профессий" или, опять же, "руководителем технического направления", в зависимости от предназначения.
Как правило же используется только один термин из двух, но если мы считаем их разными, то как этот выбор влияет на процессы? Как компании заполняют выпадающую экспертизу и ответственность?
К примеру, мы можем решить, что TeamLead это TechLead+. Т.е. это такой техлид, который дополнительно отвечает за организационные вопросы (скажем, найм, увольнение, распределение премий, мотивацию и развитие). Тогда компании, в которых есть только техлиды, перекладывают эти обязанности на руководителей направлений/отделов.
Однако это, в свою очередь, поднимает другой вопрос - откуда берутся ТимЛиды, эти сверхчеловеки, как они ухитряются поддерживать профессионализм в нескольких слабо связанных направлениях одновременно, откуда черпают мотивацию для столь высокой работоспособности и почему мы все не можем такими быть?
Или мы можем решить. что TeamLead это TechLead +/-, т.е. это технарь, который отвечает за организационные вопросы, но при этом не несёт основной ответственности за архитектуру и принятие технологических решений.
В этом случае ответственность за подобные решения несёт... кто-то ещё. Кто-то вводит роль архитектора направления/отдела, реже команды (тогда это техлид?). Кто-то полагает, что техническую экспертизу должны предоставлять ведущие разработчики (а иначе зачем они вообще нужны?), а в случае, если они не могут прийти к единодушному решению, то его принимает ТимЛид (а иначе зачем нужен он и его технарское прошлое?).
И только определившись с терминологией и, так сказать, штатной организацией, можно серьёзно разговаривать о конкретных обязанностях и проистекающих из этого затруднениях.
Романтику в программировании убила культура стартапов. Иммено оттуда пришла идея, что нам нужно выйти на рынок здесь и сейчас
Т.е. времена выхода Windows 95 вы, я так понимаю, не застали? В те времена и слова-то "стартап" не знали, а необходимость опередить конкурента с прорывным проектом - уже вполне. Ну, менеджеры - знали, IT-профи ещё долго не могли не то что принять, а просто осознать саму концепцию вывода на рынок ОС, которая виснет на постоянной основе.
Примерно в те времена в IT появилась идея, что при планировании релизов фиксировать нужно не функционал, а сроки. И я бы не назвал эту концепцию глупой, даже с точки зрения IT, не говоря уже о бизнесе в целом.
В общем, как это обычно и бывает, все инновационные идеи на самом деле изобрели ещё задолго до Потопа. :)
Я не уверен, что вы правы. Я бы скорее сравнил этот процесс с работой Team Lead-а со старательным, но не особо умным разработчиком. Только ускоренным на 3-4 порядка, а это бомба.
Вы просто представьте себе, что он для вас может изолировать любой блок кода и прогнать на нём тест с заранее оговоренным поведением зависимостей. Или собственно провести отладку - многократно делая дампы памяти и без вашего участия прогоняя разные варианты сочетания входных параметров или результата выполнения других функций, пока не воспроизведёт ошибку.
В конце концов - как насчёт того, чтобы просить его написать для вас не программу или модуль, а функцию и набор тестов для неё? Как это может замедлить разработку?
В общем, повернуться это всё ещё может по-разному, но благодушное "ай, да ладно, этого никогда не будет" сейчас выглядит скорее как wishful thinking. Мне вот скорее вспоминается задачка про озеро и ряску.
Конечно, мой хрустальный шар давно уже не тот, но...
Умение писать код перестанет быть значимым конкурентным преимуществом в течение ближайших нескольких лет. Примерно по той схеме, по которой им перестало быть умение писать код на asm-е в своё время - с каждым годом становясь всё более и более нишевым навыком.
Потому что ставить задачу для AI и подсказывать ему, как лучше исправить/дополнить результат, будет заведомо эффективнее, чем делать это самому. А он, тем временем, будет учиться у лучших в интерактивном режиме на огромном множестве реальных задач. Так что его скилл будет расти, скилл людей - падать.
Дальше изменятся уже сами языки и среды программирования - в сторону предельной лёгкости чтения кода в ущерб удобству написания и поддержки, тогда возможность писать код самому превратится в чисто теоретически доступную для 99%.
Весьма многообещающей выглядит отладка кода в production с подключённым AI. Автоматическая установка conditional breakpoints, снятие дампов памяти с восстановлением полной картины происходящего после обнаружения собственно проблемы (исключения, нарушения инварианта).
Генерация полного набора юнит-тестов для уже написанного кода с максимальным покрытием не строчек кода, но сценариев использования (с вопросом к человеку "а в этом случае как правильно" и поведением по умолчанию).
QA, как профессии (в современном понимании), по всей видимости осталось жить ровно до того момента, как эта штука превратится в набор коммерческих продуктов со специализациями по IT. Ибо валидировать сгенерированные AI по requirements тест-планы это работа скорее для product owner-а или аналитика, а интерпретировать результаты прогона автоматически написанных автоматических тестов будут AI и ведущий (по совместительству единственный) разработчик.
За дизайнеров просто откровенно страшно уже сейчас. С документаторами и техническими переводчиками ситуация едва ли не хуже.
И это всё при условии, что дальше развитие будет эволюционным, а не революционным. Добро пожаловать в дивный новый мир, как говорится.
Статья переводная и вводная одновременно, маловероятно, что автор вам ответит.
Я не претендую на особую экспертизу в этом вопросе, но сомневаюсь, что внедрение service mech окупится из-за перечисленных вами фич. Зато если вы хотите пойти в Canary Deployment, то (скажем, совместно с Argo Rollouts), можно получить реальный profit.
Ну и прозрачная с точки зрения остальной инфраструктуры система настроек кто-к-кому-имеет-право-обращаться, подпёртая сертификатами, должна, по-идее, радовать безопасников.
А вот если бы вы поделились с общественностью деталями "словили кучу проблем с ним", было бы здорово.
Я несколько о другом. В командной работе выделяют разные роли (генератор идей, зануда и т.п., их много и классификаций тоже много).
Главное - люди, как правило, имеют хорошие способности только к части этих ролей, а в других будут в лучшем случае посредственны. По сути, некоторые из них требуют противоположных личных качеств.
Для эффективной работы команде требуются носители всех или большинства ролей. Но роли и позиции в команде в общем случае не совпадают.
Собираясь в команды, люди занимают определённые должности и принимают на себя определённые роли.
Для того, чтобы закрепить в процессах подобные практики, нужно подбирать на определённые должности людей, способных эффективно брать на себя определённые роли. К сожалению, это далеко не всегда и далеко не везде возможно.
В каждой команде, безусловно, должен быть человек, исполняющий роль Критика, который критически разбирает любую идею, проверяя её на слабые места. Безусловно, такой человек должен быть ориентирован на результат, а не на процесс, и быть глубоко погружённым в пользовательские сценарии, иначе его критика не будет конструктивной.
Эта роль идеально сочетается с позицией QA. Увы, не всегда и не всем удаётся найти именно такого человека, сочетающего соответствующие компетенции с соответствующим образом мысли и интеллектом.
Собственно примерно поэтому, строго говоря, 3 Amigo это история про трёх друзей, а не про PM, Dev и QA. Если этот момент игнорировать (просто станьте ёжиками, мышки), то получается очередной (100 500) случай процесса, который мешает достигать результата, а не помогает это сделать.
А так да, ППКС.
Вообще-то, Канбан это куда больше и сложнее, чем просто "берём приоритетные задачи с доски", это нулевой уровень зрелости, так сказать. По сути, он и есть "скрам без спринтов", с соответствующими ритуалами даже.
Просто планирование работ осуществляется для отдельной стори, а не по принципу "нужно полностью набить спринт", а периодичность глобальных ритуалов, типа ретро, выбирается исходя из разумности и необходимости, а не искусственно прибивается гвоздями к спринту.
Впрочем, скрам тоже в последние годы стал более разумным, впитав некоторые идеи Канбана (цель спринта, к примеру).
Если что-то делать через задницу, то и результат закономерно выйдет из этого самого места.
Хотя про методологию расчёта "коэффициента участия" я бы с удовольствием послушал в деталях. Конечно, только при условии, что это не было полной шляпой, как это обычно бывает.
Тем не менее, сейчас ситуация в индустрии откровенно нездоровая:
вклад сотрудников в конечный результат может очевидно различаться в разы, а оклад при этом различается на десятки процентов
член команды может иметь околонулевую полезность для достижения результата, но его будут терпеть месяцами или даже годами, так как те, кто это видят и понимают, не имеют личной заинтересованности в сокращении издержек проекта в целом
бизнес заинтересован исключительно в рентабельности продукта, в то время, как исполнители практически не имеют такой заинтересованности и не мотивированы в её достижении
Результат в конечном итоге не идёт на пользу никому, а значит, ситуацию можно и нужно менять.
Менять её бизнес пытается с помощью глубоко формальных критериев (KPI), что приводит к фальсификации результата, а не достижению целей. Кроме того, бизнес пытается снизить издержки, удерживая себестоимость управляющих сигналов (читай - премиальных) как можно ниже, что обесценивает эти самые сигналы. Что мне эти ваши 10% годового дохода? Для меня это совершенно не принципиально, это не ключевой фактор принятия решений.
IT-шники, в свою очередь, не хотят понимать, насколько IT-проекты - дорогое и рискованное мероприятие. Окупаемость не просто не гарантирована - она достаточно маловероятна. Поэтому аргументация в духе "а пусть просто платят больше" - нифига не конструктивна.
Поэтому я вижу только один вариант - смещение крупного бизнеса в IT в сторону стартапной модели, где рядовые исполнители частично разделяют с основателем риски своего проекта, но при этом рассчитывают на кратное увеличение дохода в случае успеха. Да, на этой дороге тоже будет много боли, но таков путь.
Ну, лет 20 тому назад работал я в славной компании Крок. Во вполне себе "российских условиях".
И была там тогда забавная фишка - Лид команды (в тогдашних терминах компании - "Программ Менеджер") получал именно процент от прибыли проекта, которым занимался.
Это порой приводило к забавным коллизиям... но в целом - работало. Причём стать этим самым ПМ-ом было на удивление просто. Всего-то и требовалось - продемонстрировать минимальный эмоциональный интеллект и ориентированность на результат, а не на процесс и IT-шную крутость.
Про опционы рассказывать же не нужно, все и так знают? Обычная практика.
Так что нет, многие руководители и владельцы бизнеса с радостью разделят с сотрудниками прибыль при условии их готовности разделять риски.
Но вы упёрлись в глубоко третьестепенный вопрос. Главное-то другое - право команды самим перераспределять свой бюджет, никого особо не спрашивая (в разумных пределах). Но - с ответственностью за конечный результат и никак иначе.
Мы никогда не знаем, сколько времени займёт решение поставленной задачи.
Но мы имеем достаточно неплохое интуитивное представление о том, насколько сложной кажется эта задача судя по её описанию и исходя из практического опыта.
Почему, имея неплохое представление о сложности задачи, мы не можем назвать срок её решения?
А вы откройте ваш трекер и посмотрите, сколько времени НА САМОМ ДЕЛЕ занимало решение задач, изначально оцененных в N попугаев, где N - любое число, не сводящееся в конечном итоге к одному-двум часам. Что вы получите на выходе, неужели цифру? А вот и нет, вы получите диапазон цифр, примерно соответствующий нормальному распределению.
Это по факту будет так, а факты - очень упрямая вещь. Вот и скажите мне - как, прекрасно зная это, вы можете продолжать требовать в качестве ответа ЦИФРУ? Какую именно, блин, цифру? Среднюю? Девяностопроцентный персенталь? Девяностодевятипроцентный персенталь?
И почему вы вообще требуете эту цифру от технических специалистов-то? У Project Manager-а доступа к Jira нет, он сам получить нормальное распределение не может? А ведь это самое распределение и есть - единственно возможный, честный и точный ответ. Всё остальное - ложь.
И для чего эта цифра вообще нужна? Для какого такого планирования? Планирования по одной задаче? А зачем такое планирование нужно-то? Планировать нужно не одну отдельно взятую задачу, а scope этих самых задач. И вот именно для такого планирования вам и нужно честное распределение вероятностей, а не взятые с потолка субъективные цифры сомнительного качества. Потому что именно по такому, качественному набору данных, вы и можете построить свой реальный план с любой требуемой в вашем случае точностью (иными словами - с допустимым в вашем конкретном случае риском срыва планов).
Вроде бы это так просто?
Была раньше такая замечательная передача "Grand designs" про строительство нестандартных домов.
Общий вывод из просмотренных двух сезонов - все сроки и все сметы нужно умножать на 2. В смысле - полная глупость этого не делать, даже при том, что всё было просчитано профессионалами высокого класса.
Там ещё была типовая шутка "будет готово к Рождеству". В смысле - без уточнения года.
ага, бедная, отсталая рассия-матушка, где всё не так, как на прекрасном, цветущем западе, как же без этого :)
В принципе - не вопрос, но тогда эффективные программисты, конечно, тоже не откажутся внести свою лепту и согласятся перераспределить свои зарплаты таким образом, чтобы большая их часть была привязана к коммерческому успеху продукта? Практика, так-то, достаточно распространённая, но не в наших широтах.
Впрочем, тут вообще многое перебалансировать придётся, изменение отнюдь не косметическое.
Отношение к людям, как к ресурсу, характерное как для руководителей среднего звена и выше, так и для HR, как системы, оно в принципе не про эффективность. Т.е. хотите эффективности - так работать нельзя, нужен индивидуальный подход.
А индивидуальный подход, в свою очередь, он не про масштабируемость. По определению. Поэтому работает он только в маленьких коллективах.
С другой стороны, индустрия IT для работы над проектами, в том числе и масштабными, вынуждена изобретать интересные, нестандартные, подходы. Кроссфункциональные команды, agile, относительное равноправие бизнеса и технических специалистов в принятии решений.
Мне кажется, что будущее в адаптации IT-бизнеса к этому подходу с превращением как минимум продуктовых команд в условно-независимые бизнес-юниты со своим собственным бюджетом. Вася хочет повышения зарплаты? Не вопрос, какие статьи расходов нашей команды мы режем, чтобы это обеспечить?
Можно всем срезать премии. Можно уволить Колю, толку от него так-то не особо много и всяко меньше, чем от Васи. Можно сократить расходы на командную площадку в облаке, отказаться от одного из стендов и уменьшить период хранения логов до трёх дней.
Можно увеличить выручку продукта, тогда зарплату можно будет поднять не только Васе, но тогда Васе придётся подождать несколько месяцев, а результат не гарантирован.
Можно попытаться поднять цену владения командой и продуктом для материнской компании, переложив на неё издержки. Может прокатить.
А может, Федя вызовется делать работу Васи за 2/3 его зарплаты и можно просто помахать Васе платочком на прощание с наилучшими пожеланиями.
Звучит очень круто и вдохновляюще!
Было бы здорово, если вы могли бы раскрыть больше деталей про маршрутизацию на местности, объезд препятствий и избегание столкновений/пересечений с другим транспортом и пешеходами на местности, но и так спасибо за интересный материал.
Правда, лично у меня остался вопрос - такие роботы стоят очень и очень недёшево. При этом он может перемещаться, но не может быть в двух местах одновременно.
Установить стационарно полсотни таких вот газовых анализаторов и несколько десятков вебкамер в ключевых местах не дешевле вышло бы? А даже если нет, не надёжнее ли?
Что такое код, состоящий из огромных функций?
Полныманалогомэтогоявялетсятекстбезпроблеловипереводовстрок.
Что такое код, состоящий из функций, большинство которых состоят из одной-двух строк?
Ну
,
это
такой
текст , в котор
ом вооб
ще нет никак
ой структ
уры
.
Что из них хуже? Так оба хуже. Оба подхода друг-друга стоят. Ни один из них не нужно использовать.
Могу сказать за себя и только за себя.
Мне кажется, что реальный объём полезной работы, которую я могу проделать в течение рабочего дня / рабочей недели слабо связан с собственно рабочим временем. Это вопрос управления энергией, а не временем, по большей части (понятно, что пары часов в день категорически недостаточно, а вот насчёт четырёх часов я уже не вполне уверен, насчёт шести - уверен полностью).
Полагаю, я бы согласился на некоторое снижение зарплаты в обмен на дополнительный выходной. Возможно, даже на пропорциональное. Потому что интегральное качество жизни от этого только повысилось бы, мы же буквально размениваем отпущенное нам время жизни на деньги, но зачем нам деньги взамен жизни, если времени пожить не остаётся?
Сотрудники на удалёнке (с минимальным контролем) и фрилансеры, в принципе, в той или иной степени воплощают этот принцип без всяких глобальных национальных правил. Но это требует высокой самодисциплины, причём в обе стороны.
Разумеется, если бы моя работа заключалась в том, чтобы упаковывать в коробки товары с проезжающей мимо меня ленты, то приносимая мною польза была бы прямо пропорциональна рабочему времени и пункты №1 и №3 не имели бы никакого смысла. В отличие от пункта №2.
Тут как-то неявно предлагается, что в раннем ЦРУ работали мрачные серьёзные гении, скрупулёзно проработавшие теорию организации саботажа на рабочем месте.
Но с таким же успехом эту брошюру могли составить пара саркастичных мужиков, вроде нас, с опытом работы в крупных корпорациях, у которых подгорело.
Поэтому все случайные совпадения - ни разу не случайны.
Возможно, в вашей компании всё так и есть. Но я вот не согласен с таким определением - на мой взгляд, это определение ведущего разработчика, они для этого и нужны.
Больше того - нет никаких причин, по которым таких "техлидов" в команде не могло бы быть несколько. И даже больше того - в кроссфункциональной команде их и должно быть несколько (в общем случае).
Но так как единого ГОСТ-а с определениями нет, то каждая компания вправе изобретать свои собственные определения и наполнять их своим смыслом. И всё бы ничего, но при переходе из компании в компанию такие штуки порождают множество wtf-ов с обеих сторон. :)
В целом, основная проблема рассуждений про обязанности лидов - в крайне расплывчатой формулировке этого понятия, которое очень сильно различается от компании к компании.
К примеру - есть два созвучных термина, ТимЛид и ТехЛид. Это одно и то же или это разные вещи? Большинство компаний просто выбирают один из этих терминов и не парятся по поводу деталей. Сама же идея того, что команде нужен технический руководитель, мягко выражаясь, не нова, вот и берётся современный термин для старой, как IT, концепции.
Лучше всего, в теории, на этот вопрос могли бы ответить компании, которые в штатном расписании имеют и тех и других. Я знаю две таких компании.
В первой команды разрослись до неприличных размеров и их реорганизовали, добавив дополнительный уровень иерархии. "Большую" команду возглавляет ТимЛид, а "маленькие", из которых состоит "большая", возглавляет "техлид". Но с таким же успехом можно было бы объявить "большую" команду - "отделом" или "направлением", которую возглавляет "руководитель направления", это было бы даже честнее.
Во второй компании использовали post-spotify матричную модель, в которой ТимЛиды возглавляли команды, а ТехЛиды - технические направления (backend, frontend, devops и т.п.). Эти товарищи просто использовали термин "ТехЛид" для обозначения относительно новой роли, которую правильнее было обозвать "лидерами профессий" или, опять же, "руководителем технического направления", в зависимости от предназначения.
Как правило же используется только один термин из двух, но если мы считаем их разными, то как этот выбор влияет на процессы? Как компании заполняют выпадающую экспертизу и ответственность?
К примеру, мы можем решить, что TeamLead это TechLead+. Т.е. это такой техлид, который дополнительно отвечает за организационные вопросы (скажем, найм, увольнение, распределение премий, мотивацию и развитие). Тогда компании, в которых есть только техлиды, перекладывают эти обязанности на руководителей направлений/отделов.
Однако это, в свою очередь, поднимает другой вопрос - откуда берутся ТимЛиды, эти сверхчеловеки, как они ухитряются поддерживать профессионализм в нескольких слабо связанных направлениях одновременно, откуда черпают мотивацию для столь высокой работоспособности и почему мы все не можем такими быть?
Или мы можем решить. что TeamLead это TechLead +/-, т.е. это технарь, который отвечает за организационные вопросы, но при этом не несёт основной ответственности за архитектуру и принятие технологических решений.
В этом случае ответственность за подобные решения несёт... кто-то ещё. Кто-то вводит роль архитектора направления/отдела, реже команды (тогда это техлид?). Кто-то полагает, что техническую экспертизу должны предоставлять ведущие разработчики (а иначе зачем они вообще нужны?), а в случае, если они не могут прийти к единодушному решению, то его принимает ТимЛид (а иначе зачем нужен он и его технарское прошлое?).
И только определившись с терминологией и, так сказать, штатной организацией, можно серьёзно разговаривать о конкретных обязанностях и проистекающих из этого затруднениях.
Т.е. времена выхода Windows 95 вы, я так понимаю, не застали? В те времена и слова-то "стартап" не знали, а необходимость опередить конкурента с прорывным проектом - уже вполне. Ну, менеджеры - знали, IT-профи ещё долго не могли не то что принять, а просто осознать саму концепцию вывода на рынок ОС, которая виснет на постоянной основе.
Примерно в те времена в IT появилась идея, что при планировании релизов фиксировать нужно не функционал, а сроки. И я бы не назвал эту концепцию глупой, даже с точки зрения IT, не говоря уже о бизнесе в целом.
В общем, как это обычно и бывает, все инновационные идеи на самом деле изобрели ещё задолго до Потопа. :)
Я не уверен, что вы правы. Я бы скорее сравнил этот процесс с работой Team Lead-а со старательным, но не особо умным разработчиком. Только ускоренным на 3-4 порядка, а это бомба.
Вы просто представьте себе, что он для вас может изолировать любой блок кода и прогнать на нём тест с заранее оговоренным поведением зависимостей. Или собственно провести отладку - многократно делая дампы памяти и без вашего участия прогоняя разные варианты сочетания входных параметров или результата выполнения других функций, пока не воспроизведёт ошибку.
В конце концов - как насчёт того, чтобы просить его написать для вас не программу или модуль, а функцию и набор тестов для неё? Как это может замедлить разработку?
В общем, повернуться это всё ещё может по-разному, но благодушное "ай, да ладно, этого никогда не будет" сейчас выглядит скорее как wishful thinking. Мне вот скорее вспоминается задачка про озеро и ряску.
Конечно, мой хрустальный шар давно уже не тот, но...
Умение писать код перестанет быть значимым конкурентным преимуществом в течение ближайших нескольких лет. Примерно по той схеме, по которой им перестало быть умение писать код на asm-е в своё время - с каждым годом становясь всё более и более нишевым навыком.
Потому что ставить задачу для AI и подсказывать ему, как лучше исправить/дополнить результат, будет заведомо эффективнее, чем делать это самому. А он, тем временем, будет учиться у лучших в интерактивном режиме на огромном множестве реальных задач. Так что его скилл будет расти, скилл людей - падать.
Дальше изменятся уже сами языки и среды программирования - в сторону предельной лёгкости чтения кода в ущерб удобству написания и поддержки, тогда возможность писать код самому превратится в чисто теоретически доступную для 99%.
Весьма многообещающей выглядит отладка кода в production с подключённым AI. Автоматическая установка conditional breakpoints, снятие дампов памяти с восстановлением полной картины происходящего после обнаружения собственно проблемы (исключения, нарушения инварианта).
Генерация полного набора юнит-тестов для уже написанного кода с максимальным покрытием не строчек кода, но сценариев использования (с вопросом к человеку "а в этом случае как правильно" и поведением по умолчанию).
QA, как профессии (в современном понимании), по всей видимости осталось жить ровно до того момента, как эта штука превратится в набор коммерческих продуктов со специализациями по IT. Ибо валидировать сгенерированные AI по requirements тест-планы это работа скорее для product owner-а или аналитика, а интерпретировать результаты прогона автоматически написанных автоматических тестов будут AI и ведущий (по совместительству единственный) разработчик.
За дизайнеров просто откровенно страшно уже сейчас. С документаторами и техническими переводчиками ситуация едва ли не хуже.
И это всё при условии, что дальше развитие будет эволюционным, а не революционным. Добро пожаловать в дивный новый мир, как говорится.
Статья переводная и вводная одновременно, маловероятно, что автор вам ответит.
Я не претендую на особую экспертизу в этом вопросе, но сомневаюсь, что внедрение service mech окупится из-за перечисленных вами фич. Зато если вы хотите пойти в Canary Deployment, то (скажем, совместно с Argo Rollouts), можно получить реальный profit.
Ну и прозрачная с точки зрения остальной инфраструктуры система настроек кто-к-кому-имеет-право-обращаться, подпёртая сертификатами, должна, по-идее, радовать безопасников.
А вот если бы вы поделились с общественностью деталями "словили кучу проблем с ним", было бы здорово.