Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
Senior Business Process Analyst
  • «Через п’ять років програмістів-людей не буде», — очільник Stability AI

    Так, не все так просто. Якщо виникає питання заміни легасі, яку вже не можна підтримувати далі (а її дійсно вже не можливо підтримувати далі сьогодні), то перше, що бізнес-відповідальні люди повинні зробити — запитатись, чи є вирішення цієї проблеми, та в чому воно є? Думеєте, бізнес-відповідальні люди не скористаються ChatGPT щоб отримати відповідь? :) Якщо в Вас є сумніви, що бізнес-відповідальні люди отримують належну відповідь через декілька ітерацій, Ви втрачаєте адекватність просто тому, що Вам не подобається об’єктивна реальність...

    Підтримав: Philip Pristupa
  • «Через п’ять років програмістів-людей не буде», — очільник Stability AI

    Да, далека. Подтверждаю, как свидетель тех самых времен — 15-20 лет назад.

  • «Через п’ять років програмістів-людей не буде», — очільник Stability AI

    Якщо AI Subscription буде дешевше ніж найєм програміста, Goodbye my love, goodbye... Питання в тому, чи ви взмозі демпінгувати і далі, як всі наші власники гелєр звикли у скрутні часи?

  • «Через п’ять років програмістів-людей не буде», — очільник Stability AI

    Думаю, значно раніше! :)

  • «Через п’ять років програмістів-людей не буде», — очільник Stability AI

    Навіть програмісти на асемблері та фортрані, потребують щоб хтось сформулював для них завдання — що робити. Саме з тих часів, коли асебмблер та фортран були в тренді, жодного разу не бачив в очі програміста який без належного тлумача одразу розумів, що треба програмувати. Сьогодні, коли тлумачення того, що треба робити перетворюється в промпт-інжинірінг, доля фортран- або асемблер-кодера може вважатись вирішеною... :)
    До того ж, якщо Ви бачите, що десь програмісти фортрана чи асемблера ще не зникли, то значить тількяи те, що AI до цих дрімучих глушин ще не дістався... :)

  • «Через п’ять років програмістів-людей не буде», — очільник Stability AI

    Навіть якщо Ваш персональний добробут не залежить від хедж фондів, це не не значить, що цей індус не дістанеться до Вас... :)

  • Гетманцев заявив, що ніколи не пропонував айтішникам відмовитися від ФОПів чи співпраці з юрособами

    Вы точно подметили ключевой момент всей этой затеи. Эти две ключевые бумажки Вы сможете увидеть только непосредственно перед подписанием.

    Підтримав: gitmitos
  • Как эффективно управлять DevOps-командой. Советы проектным менеджерам

    Зачем сразу так плохо о ПМе? :) Как говорится, не стреляйте в пианисткe, она играет, как может! :) В той ситуации, в которую попала. Другое дело, что попытка натянуть практики проектного менеджмента на сугубо сервисную функцию девопс выглядит, мягко говоря, не совсем адекватно. Здесь реально рулит классика ITIL/ITSM. Между разрабами и командой девопсов должен быть SLA с оговоренными сроками реагирования на заявки. Да и вообще, весь процесс лучше отслеживать не как задачи в обычной Jira Software для управления проектами разработки, а как тикеты в Jira Service Management.

  • Как эффективно управлять DevOps-командой. Советы проектным менеджерам

    Ну, скрам нужен не для продуктивности. Иногда (а вернее — во многих случаях), заказчику нужно регулярно (например — раз в 2 недели) показывать что-то работающее. Дабы у него не пропадало желание и дальше оплачивать работу :). Ежели команда не в состоянии показывать прогресс ежедневно, топчется на месте и у нее всегда все в in-progress, вот тогда — scrum может и помочь. Если с умом подойти...

  • Гребцы и капитаны

    Это верно! Вот если еще «менеджера» переименовать в старорежимного «приказчика» на службе у «заводчика» — то все становится на свои места :)

  • Как эффективно управлять DevOps-командой. Советы проектным менеджерам

    Канбан — абсолютно адекватный подход. Тойота. Классика конвейера. Pull system. Задачи вытягиваются из бэклога тогда, когда высвобождается ресурс для ее выполнения, а не тогда, когда наступает какой-то высосанный из пальца дедлайн. Вообще — нехорошо высасывать из пальца. Как минимум — это не гигиенично... :)

  • Как эффективно управлять DevOps-командой. Советы проектным менеджерам

    Внезапно! Менеджмент может выдать любую глупость за полезную штуку :)

  • Как эффективно управлять DevOps-командой. Советы проектным менеджерам

    Точно! Натянули сову на глобус и радуются... :)

    Підтримав: Олексій Пєніє
  • Как избежать неправильного оценивания проектов

    Интересно, кто платит за такое счастье? :)

  • Как избежать неправильного оценивания проектов

    Точно! Иногда выбрасывание чего-то из продукта ведет к множественным переделкам в других местах. Ибо любая система — не есть простая сумма входящих в нее компонент. Впрочем, для многих менеджеров это не вполне очевидно... )))

  • Как избежать неправильного оценивания проектов

    Вотерфол — это когда дизайн не начинается, пока не утверждены все требования, а девелопмент не стартует, пока не утвержден весь дизайн, а тестирование не начинается, пока не готов весь код. Полагаю, реально это имеет место разве что в строительстве. Где колышек в землю не вобъешь без получения разрешения землеустроительных инстанций, а строительство не начнешь, пока не будет утверждена вся проектная документация, ну а дальше — понятно, нельзя строить 5-й этаж, до того, как будет построен четвертый :) .... Для фиксед прайс имеет значение только одно — чтобы требования, определяющие объем работ, были зафиксированы вместе с договорной ценой до начала работ. Подчеркиваю — до начала работ! И всякое изменение требований после старта проекта должно приводить к пересмотру бюджета и сроков. В этом вся суть фиксед прайса. К вотерфолу это не имеет ни малейшего отношения. Тем более, что более-менее детальный WBS, из которого вытекает бюджет и цена проекта, с самого начала включает эволюционный жизненный цикл со всеми возможными вариантами максимального распараллеливания работ.

  • Как избежать неправильного оценивания проектов

    Да, слова аджайл мы тогда не знали, Дима :). Однако, было примерно так:

    1. Были алгоритмисты (очень много), которые по стандарту, придуманному программерами, рисовали алгоритмы бортовой системы управления полетом КА (космического аппарата), исходя из его предназначения. Там было все и управление ориентацией объекта и коррекция орбиты и решение множества всяких служебных задач, включая управление многочисленными системами и устройствами аппарата. Алгоритмы рисовали сверху вниз — от самых высокоуровневых (типа дистетчера задач) до самых низовых. Начинали сверху — общая логическая схема режима функциониррования системы управления, согласовывали и сразу отдавали программерам. Потом переходили к детализации и по мере готовности отдавали программерам. При необходимости корректировали общую схему режима и тут же передавали ее программерам

    2. Программеры работали параллельно с алгоритмистами. Их тоже было много. И они тоже выкатывали новые версии софта на комплексный стенд отработки практически раз в два дня. В крайнем случае — не реже раза в неделю. Новые вресии содержали пустышки в тех местах, где еще было не готово. К каждой версии прилагался список пунктов программы отработки, которые имело смысл прогонять на стенде. Здесь надо отметить, что программу отработки с описанием тест-кейсов выпускали и обновляли алгоритмисты по мере выкатывания алгоритмов. Таким образом тестировщики (испытатели) на комплексном стенде имели актуальный план действий.

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

    4. Пара слов об управлении проектом. Поскольку не только софт, но и железо для системы управления создавалось и изготавливалось на заводах параллельно, был общий сетевой график по изделию, в котором отражались обязательства многочисленных участников этого дела. Глобально было несколько клюевых вех, отражавших зрелость конечного продукта. От стендовых прототипов до финальной готовности к летным испытаниям таких этапов могло быть до десяти и больше. В конце каждого этапа выкатывался релиз полностью отработанного софта с ограниченным функционалом, необходимым для отработки задач следующего этапа. Весь функционал необходимый для летных испытаний появлялся только к финалу. Внутри каждого этапа, как я уже писал, функционал наращивался и отрабатывался инкрементально. Своего рода канбан... Надо также сказать, что вместе с софтом на комплексном стенде отрабатывалось и многочисленное железо, которое тоже делалось и доводилось до ума инкрементально от макета до пригодного к работе в условиях реального полета образца. Железо конечно релизилось реже... :)

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

    И да — забыл отметить. Это был типичный Time & Material. Если где-то и было бюджетное ограничение, то ближе к пуску его все одно снимали. Премии и всякие стимулирующе-мотивирующие плюшки только росли...

  • Схватка двух ёкодзун: ITIL vs PMBoK

    Ну здесь все просто. Определитесь, зачем вам нужен CAB? Какую конкретно проблему, как Вам кажется, это может решить? Пока не ответите себе на этот вопрос, нет никакого смысла обсуждать, как оно будет сожительствовать с помянутыми подходами... :)

  • Схватка двух ёкодзун: ITIL vs PMBoK

    Тема действительно интересна. Как по мне, то если речь идет о развитии компетенции Service Management в компании, то я бы все-таки отодвинул PMBoK на второй план и сделал бы упор на ITSM (ITIL). С другой стороны, ITSM — уж очень монструозен, и если речь идет о быстром развитии компетенции с нуля или околонуля, то стоит присмотреться к вышедшей недавно модели CMMI v2.0. CMMI Institute сделал большой шаг вперед по сравнению с версией 1.3. В новой версии реально интегрированы Development, Services и Acquisition, убрано дублирование, радикально упрощен язык. Модель стала понятна не только спецам, но и бизнесменам... :) И, мне кажется, это лучше ITIL.

  • Упал еще один Boeing 737 MAX

    В полете — да. Но в данном случае ФБР и Минюст уже начали выемку документов и проверку всей процедуры прохождения сертификации 737МАХ.

← Сtrl 12 Ctrl →