Продакшен, производственная среда или...
Подскажите, пожалуйста, какой термин вам понятнее:
продакшен,
"боевой" сервер,
производственная среда,
производственное окружение,
промышленная среда,
промышленное окружение,
live сервер,
prod,
production,
PROD.
Нужно для будущей книги. Хочу написать так, чтобы читатели потом поняли, что я имею в виду.
Инженер Google выпустил бесплатный учебник для всех, кто хочет создавать ИИ-агентов и изучить работу нейросетей. Там собрана вся информация от А до Я про ИИ-агентов, включая продвинутые техники промптинга, тонких настроек, обучение агентов пользоваться браузером с практическими примерами с кодом.
«СберТех», Cloud.ru и Хабр заколлабились и запустили грантовую программу «Код без границ». Это отличная мотивация для разработчиков и ресурсы для проектов. Можно доработать свой проект с поддержкой сообщества, найти единомышленников и показать свои возможности.
Участвовать просто:
разместить свой проект на GitVerse (СберТех) или импортировать его с другой площадки.
делится кодом и вдохновляться чужими разработками.
Номинации следующие: ИИ‑инновации, «Наука и образование», «Проекты для всех», «Разработка для разработчиков».
Заявки на грантовую программу «Код без границ» принимаются с 3 сентября по 31 октября. Отбор проведут в ноябре, а результаты огласят в декабре.
Почему календарь — больше, чем просто даты?
Ежедневники, записки на листочках, приложения или просто календарь. Обычный календарь для планирования, записи дел, для жизни, учебы или работы. Если сентябрь для вас — не просто дата, а повод задуматься о переменах, тайм-менеджменте и новых смыслах, то обязательно загляните в новую статью «Календарь всемогущий: идеальный инструмент планирования».
В ней:
Почему список задач работает не так эффективно, как хотелось бы.
Как использовать колесо баланса.
Почему рабочий год можно начинать не только первого января, но и первого сентября.
Как использовать календарь для осознанного проектного планирования.
Неожиданные советы для всех, кто управляет временем, проектами и собственной карьерой.
Лайфхаки, примеры из опыта автора и простые принципы для продуктивности ждут вас внутри!
«Первая Форма» заняла второе место в рейтинге систем управления проектами
CNewsMarket выпустил рейтинг систем для управления проектами, в котором сравнил возможности планирования, контроля этапов работ и управления информацией о ресурсах разных решений. «Первая Форма» заняла вторую строчку — система получила наибольшее количество баллов по функциональности и архитектурным решениям.
Топ-10 систем проектного управления в 2025 году
Критерии оценки
Эксперты CNewsMarket отмечают, что до 2022 года в сегменте ПО для управления проектами лидировали зарубежные решения — Microsoft Project, Oracle и Atlassian. Но итоги 2024 года показали, что российские системы уже активно используются не только в государственном секторе, но и в крупных корпорациях.
«В отличии от таск-трекеров, решения для управления проектами позволяют планировать, отслеживать и перераспределять любые ресурсы по проекту — от рабочего времени до материальных ценностей. Такие системы, к примеру, позволяют учитывать не только рабочее время сотрудника на конкретную задачу, но и его компетенции, занятость на других проектах, график отпусков и прогнозировать трудозатраты исходя из нормативно установленных значений»
CNewsMarket
Полная версия рейтинга с распределением баллов →
Система управления проектами «Первая Форма» получила 495 баллов.
Возможности решения
Эксперты отметили широкие возможности low-code платформы для индивидуальной настройки. В системе реализована поддержка Agile- и Waterfall- методологий, она позволяет проводить план-факт анализ с любой детализацией, а также отображать отчётность по проекту на дашбордах.
Функции системы:
Возможность вести проекты более 10 тыс. задач;
Импорт проектов из MS Project;
Возможность отслеживать критический путь и использовать базовые планы;
Канбан-доски с гибкой настройкой карточек задач;
Паспорт проекта с автоматическим расчётом финансовых показателей;
Автосоздание рабочих задач для исполнителей в системе;
Возможность общаться в комментариях к задачам и в ВКС;
Визуализация отчётов на дашбордах.
Delivery Manager: где его место среди Project, Product и Program Manager?
Недавно я публиковал статью о различиях Project Manager, Product Manager и Program Manager. В комментариях закономерно возник вопрос: "А где же Delivery Manager?"
Давайте разберёмся!
В базовой статье я сознательно ограничился тремя ролями - PM, PdM, PgM.
Это клубок который действительно может ввести в ступор даже бывалых, который часто встречается в IT и лучше всего показывает разницу между управлением проектами, продуктами и программами.
Delivery Manager - роль более "нишевое" явление, сильно зависящее от конкретной компании и её процессов. В разных организациях она трактуется по-разному: от старшего PM-а до операционного менеджера в Agile-команде. Поэтому в коротком сравнении Delivery Manager легко внести больше путаницы, чем пользы.
Чем отличается: Delivery Manager = фокус на выполнении обязательств команды и стабильности поставки.
Project Manager отвечает за проект: сроки, бюджет, риски.
Product Manager отвечает за ценность и развитие продукта.
Program Manager отвечает за синхронизацию множества проектов и продуктов.
Delivery Manager отвечает за то, чтобы команда реально и предсказуемо доставляла результат, а процессы разработки и поставки не ломались.
Задачи Delivery Manager-а
Следить за здоровьем процессов в команде (Agile церемонии, velocity, SLA).
Снимать операционные блокеры, чтобы команда могла работать.
Координировать взаимодействие с другими командами (DevOps, QA, Support).
Мониторить метрики поставки.
Когда Product Manager уходит в стратегию и общение с рынком, а Project Manager в бюджет и отчётность, команде часто нужен человек, который держит фокус на ежедневной предсказуемости поставки. В крупных организациях Delivery Manager становится опорой для нескольких команд разработки, снимая с PdM и PM часть операционных забот.
Метрики эффективности Delivery Manager:
Velocity & Throughput - стабильность скорости команды.
Lead Time & Cycle Time - скорость прохождения задач.
Defect Rate - качество поставки.
Team Satisfaction - насколько комфортно команде работать в текущем процессе.
Delivery Manager - это не конкурент Project/Product/Program Manager, а их дополнение.
PM, PdM и PgM отвечают за "что и зачем" (стратегия, ценность, цели).
Delivery Manager отвечает за "как именно" на уровне повседневной работы команды.
Поэтому я не включил эту роль в основное сравнение: у неё более прикладной и контекстный характер, зависящий от культуры компании. Но там, где она есть, Delivery Manager становится связующим звеном между стратегией и ежедневной поставкой.
А у вас в компаниях, есть ли отдельные Delivery Manager-ы или их функции выполняют PM/PdM?
ML Impact — рассказываем, как компании внедряют ML и что из этого получается
Мы запустили ресурс о том, как эффективно использовать искусственный интеллект в рабочих задачах. Уже доступны материалы про настоящую роль ИИ в автоматизации и работу EDGE AI. Скоро появятся новые статьи!
Их можно использовать, чтобы обосновать коллегам или руководству целесообразность запуска ML-проекта. У вас под рукой будет готовый ресурс, которым можно просто поделиться — вместо тысячи слов и долгих объяснений.
Процессы и спагетти-чарт (что это)
Много раз наблюдал, насколько наше ожидания того, как работают те или иные процессы и как команда выполняет свою работу расходятся с суровой реальностью. Вроде есть и процедуры и инструкции и базовое понимание. Но как только начинаешь смотреть на фактическое "что происходит" - открывается дивный новый мир.
Почему это происходит? Любой бизнес, особенно в период бурного роста или становления, вынужден реактивно решать возникающие проблемы. В итоге, каждый процесс постепенно обрастает все новыми дополнениями, которые в какой -то момент, превращают его (процесс) в плохо сшитого Франкенштейна. А это, в большинстве своем, создает все больше неэффективностей, которые бьют по P&L и добавляют головной боли собственникам и руководителям.
В какой-то момент времени люди приходят к тому, что неплохо было бы понять, а что происходит, почему деньги утекают в чёрную дыру и как это остановить. Причем очень часто, дойдя до необходимости что-то исправлять, одни пытаются сделать что-то на интуиции, а другие включают научный подход и используют инструменты, которые себя давно зарекомендовали.
Одним из таких инструментов первичного анализа является спагетти-диаграмма. В производственных организациях - это крайне попклярный и простой инструмент, который поможет получить представление того, что делается.
Условная ситуация: менеджеру надо разобраться с тем или иным процессом (например, на производстве), и у него в голове есть своя прекрасная картина мира. Вот сотрудник берёт деталь А, устанавливает на станок, досылает упаковочный материал В, нажимает на кнопку — и всё. Возможно, это даже описано в стандартах. По факту же всё, мягко говоря, не так .
Чтобы это понять (и собственно сделать диаграмму) берётся листок бумаги, на котором схематично отмечаются основные рабочие точки, а затем в режиме реального времени начинаются наблюдения за перемещениями сотрудника (или его действиями) и их зарисовка. В итоге то, что у тебя окажется на листе бумаги, будет сильно отличаться от идеальной картины и будет напоминать спутанные провода или тарелку макарон (откуда и название). Этот, казалось бы, хаотичный эскиз даст быструю и реальную картину происходящего, а также поможет быстро увидеть, где совершаются лишние действия, где есть простои, где сотрудник слишком далеко ходит и так далее.
Были случаи, когда, зарисовав текущее состояние, менеджеры сразу провели реорганизацию рабочего места, переставили материалы и повысили производительность на десятки процентов! Прелесть подходаименно в том, что если оптимизациями занимались слабо или хаотично, применение простых инструментов сразу даст очень ощутимый результат.
Резонный вопрос: "а где еще можно применять данную методологию, кроме производства". На самом деле, практически везде, где есть комплексные процессы — от работ на складах до операционной работы в офисе. Подобное упражнение можно проводить на уровне кросс-функциональной команды, чтобы разобраться с потоком согласований и принятия решений. Или проанализировать работу проектной группы и понять, как на самом деле внедряются проекты.
Инструмент — крайне рекомендован к использованию, в том числе для тех, кто только погружается в новую сферу деятельности и хочет оперативно разобраться с тем, что происходит. Выхлоп, который можно получить, существенно превысит затраты. Самое главное, чего ни в коем случае нельзя делать пытаться рисовать так, чтобы подогнать под свою (желаемую) картину мира.
Если заинтересовало и хотите читать больше про менеджмент и инструменты оптимизации - приходите на канал
Ну что вы скажете? С 12 минут до 3 секунд(!) сократил время поиска инструкций полнотекстовый поиск в KMS Gran.
Один из наших клиентов - IT-компания - хранила документацию в Google Docs и Telegram, что вызывало путаницу. В 2024 году внедрили базу знаний KMS Gran, создав разделы "Проекты", "API-документация" и "Ошибки и уроки".
Результат спустя год:
время поиска инструкций сократилось до 3 секунд
скрипты автоматизировали уведомления о новых версиях API, уменьшив время согласования релизов на 30%.
за 6 месяцев количество багов в коде снизилось на 25%, так как разработчики быстро находили решения по прошлым ошибкам.
Статистика показала, что раздел "Ошибки и уроки" просматривали 80% команды, что привело к добавлению видео-разборов типичных ошибок.
А какие процессы хотелось бы улучшить в вашей команде?
Что почитать проджект менеджерам (и не только проджект)
Самое смешное, что мне этого автора рекомендовали не один раз, но я упорно рекомендацию игнорировал, так как бизнес-литературу вообще недолюбливаю. Я периодически себя заставляю ее читать, но для меня это обычно проходит с болью: либо это сухо написанная, душноватая теория с некоторыми абстрактными кейсами, либо книга, где автор через каждые пару страниц напоминает, какой он крутой и сколько денег он зарабатывает в секунду (не верите? Ден Кеннеди — пример).
Автор который меня реально удивил и чьи книги я бы назвал супер полезными - Элияху Голдратт, а его книги «Цель: процесс непрерывного совершенствования» и «Критическая цепь»— это настоящие пособие для тех, кто занимается менеджментом и хочет понимать принципы, цели и проблемы бизнеса как сложного механизма (а еще, как со всем этим справляться), а еще понимать, как стоит и не стоит управлять сложными проектами с точки зрения ресурсов и времени.
В чем основное ВАУ автора? Дело в том, что что книги вроде как не совсем учебник, а написаны в формате романа. Не ожидая чего-то прям невообразимого, я сел за чтение… и все. Оторваться совершенно невозможно!
«Цели..» - это история директора загибающегося завода и его битвы за то, чтобы их не закрыли к чертям. Через его проблемы, поражения и победы происходит понятное и практически применимое раскрытие основных принципов организации высокоэффективного бизнеса
«Критическая цепь» - в схожем стиле, но с новыми героями, рассказывает про разработку нового, более практичного метода управления проектами, который основывается на теории ограничений
И самое классное: ты не просто читаешь про какие-то абстрактные теории и героические кейсы, а за счет интересного повествования оказываешься полностью погружен в проблему, сопереживаешь герою и подсознательно пытаешься найти решение.
Спойлеры излишни, но, жти произведения реально помогут лучше разобраться в том:
как определить правильную цель своего бизнеса;
из-за чего даже самое передовое предприятие может рухнуть;
что за «узкие места», как с ними бороться и как не создать новые;
почему работа отнимает все отведенное на нее время;
как ускорять выполнение проектов при ограниченных ресурсах;
как сделать процесс совершенствования постоянным и чем, должны заниматься настоящие руководители.
Ну и многое другое. Короче, всем менеджерам — в список к прочтению под номером 1!Прочитав, я жалею о двух вещах. Первое — что не прочел книжки раньше раньше (и это не фигура речи). Это крутой бизнес-учебник. Второе — что они слишком быстро кончились. Но это дает повод больше познакомиться с творчеством автора.
Если вам нравится читать и узнавать про бизнес и менеджмент, то приходите на мой канал
Мы выбрали 10 топ-хабрастатей за 10 лет, а вы выберите лучший HR-бренд
Будем краткими: в этом году блогу МойОфис на Хабре исполнилось 10 лет!
Мы собрали юбилейную подборку — выбрали по одной ключевой статье на каждый год. Это тексты, без которых, как говорится, нас невозможно представить, еще труднее – понять!
А вас просим оценить нас в ежегодном опросе Хабр/ЭКОПСИ. Это займёт всего 5–7 минут. Мы соберём важную обратную связь, а индустрия получит объективную картину IT-брендов в 2025 году.
Про Haier, перемены и молотки
Я тут писал про управление изменениями и, погрузившись в тему, начал изучать разные прикольные кейсы. Одним из тех, которые я накопал был пример того, как Haier из умирающего завода превратился в мирового гиганта, который останавливаться вообще не собирается.
А лет 10 назад про него не то, чтобы много знали... Сам помню, когда покупал бытовуху для квартиры и пытался найти что-то, чтобы не потратить все свои кровные, бодрый консультант показал мне на стиралку Haier и долго расписывал, какая она вся из себя.
Страна происхождения вызывала у меня тогда большие сомнения, но так как Бош стоил раза в два дороже, то я поддался (кстати, не жалею). И вот за несколько лет бренд из очередного китайского фиг-пойми-кого превратился чуть ли не в «почти» премиум (а уж на фоне триллиона всяких Ноунеймов — уж точно премиум).
А мало кто знает, что Haier, который сейчас делает по 40 млрд $ в год и растёт по обороту и прибыли, в 80-х был маленьким заводом и реальным позором любого управленца. В 2000-х они снова пережили жёсткую стагнацию и были вынуждены срочно что-то делать, чтобы не растерять всё, что накопили за пару десятков лет.
И мне стало интересно, что менеджмент поменял за последние годы (а было несколько вау-перемен), чтобы из умирающей фабрики сделать гиганта, который в один момент без особых проблем купил часть General Electric.
Самая прикольная история началась в 1984, где был финансовый минус, молотки и холодильники.
Собственно, всё было плохо. Постоянно растущий долг, дикая бюрократия и просто отвратительное качество. Процент брака составлял безумные 20%+, а надо сказать, что холодильник в то время в Китае был довольно дорогостоящим девайсом. Короче, всё шло к предсказуемому финалу. Однако в декабре город, понявший, что скоро всему придёт капец, быстренько назначил нового гендира Чжан Жуйминя.
Придя на новую роль, он тут же смекнул, что основная его проблема лежит в ужасающем качестве продукции. И дело даже не в том, что это проблема прямо сейчас, а в том, что даже если качество будет удобоваримым, это не поможет компании расти и вынести конкурентов.
Самый эпичный эпизод в процессе внедрения системы тотального качества — публичное уничтожение молотками бракованных холодильников (как обещал). Народ, видя, как разрушают дорогостоящий девайс, реально плакал и просил продать со скидкой. Но новый гендир (по легенде) сказал: «Если мы сегодня не уничтожим эти холодильники, завтра рынок уничтожит нас».
После этого он резко развернул фокус компании от погони за количеством к тотальному контролю качества. Чтобы не изобретать велосипед, они начали активно перенимать технологии от Liebherr и даже сделали совместное предприятие. А для того, чтобы это всё прижилось, они внедрили систему OEC — своего рода Lean, в основе которой лежит идея улучшения каждой задачи, которую человек выполняет ежедневно.
За счёт таких перемен завод не просто вылез из ямы, но начал расти, используя стратегию поедания больных рыб. Они поглощали убыточные, умирающие предприятия и делали их прибыльными.
Результат мы знаем. Сейчас Haier — одна из самых крупных компаний-производителей всякой техники, а Чжан Жуйминь рулит компанией уже много десятилетий.
Мораль проста. Как только компания (отдел, команда) перестаёт меняться и подстраиваться к реалиям — это прямая дорога к провалу. Фокусное, стратегически взвешанное и последовательное внедрение изменений (даже самых революционных) позволяет компаниям реально перезагрузиться и выйти на новый виток развития.
Если было интересно читать, пожалуйста, лайкните. А еще про менеджмент, бизнес и управление изменениями я пишу на своем канале. Буду рад, если зайдете почитать
Как сделать так, чтобы дизайнер и фронтендер не ругались
Противостояние дизайнеров и разработчиков носит уже почти легендарный характер. Этой теме посвящены десятки статей, видосов и докладов. Однако мы в компании уверены: чтобы лучше понимать друг друга, нужно просто следовать элементарным правилам.
1. Больше общаться.
Будет круто проводить кросс-функциональные встречи, потому что единое информационное поле — всегда хорошо. Можно даже назначить «дежурных» по взаимодействию — это ответственные люди от разработки и от дизайна, которые будут время от времени срезаться и обсуждать наболевшие вопросы.
Кроме того, если подключать фронтендера на этапе разработки прототипа, он сразу сможет подсказать, что будет сделать легко, а что сложно.
2. Следить за актуальностью UI-кита.
Это база. Чтобы всем было удобно работать, в макете должен быть UI-кит. Разработчик сразу будет видеть, какие шрифты и UI-элементы возникнут в проекте. И конечно, UI-кит важно оперативно обновлять и сообщать об этом отделу фронтенда.
3. Внедрять общий процесс на всех уровнях.
Во-первых, стоит настроить взаимное ревью: разработчик смотрит дизайн, прежде чем взять его в работу, а дизайнер — готовую страницу. Во-вторых, полезно использовать общие чек-листы. Например, у нас макет нельзя передавать дальше, пока не отрисованы все состояния. И в-третьих, хотя бы иногда нужно проводить совместные ретроспективы.
Общее же правило, как и в любой коммуникации — быть готовыми к компромиссам и доверять друг другу. Подробнее о правилах коммуникации между отделами дизайна и фронтенда мы рассказали в нашем блоге.
Я узнал о... #3: DevOps фреймворк DORA
DORA - это DevOps фреймворк из 4-х метрик, которые помогают оценить эффективность и качество релизного процесса.
Фреймворк придумала компания с таким же названием (DevOps Research and Assessment). Скорее всего, чтобы проще продавать свой консалтинг. В 2018-м году эту компанию купил Google Cloud и сделал своей... командой.
Вообще, про эти метрики в том или ином виде я знал. Но не знал, как они систематизированы и по-умному называются.
Собственно, сами метрики:
1) Частота деплоя (deployment frequency)
Показывает, насколько адекватный уровень автоматизированного тестирования. И умеет ли команда релизить точечно, а не сразу всё.
Критерии:
отлично: несколько раз в день;
хорошо: раз в 1-7 дней;
средне: несколько раз в месяц;
плохо: реже, чем раз в месяц.
2) Время от коммита до деплоя (Lead Time)
Показывает, как долго мы тормозим с бюрократией после момента, когда код уже готов. Низкое значение - неэффективное тестирование, процессы ревью или разработки.
Критерии:
отлично: меньше дня;
хорошо: от 1-го до 7 дней;
средне: 7-30 дней (*по оценке компании DORA, я бы сказал, что это плохой результат);
плохо: дольше месяца.
3) % сбоев после релиза (Change Failure Rate)
Показывает, как часто мы ломаем прод релизами. Что говорит о том, насколько хорошо мы прорабатываем требования, умеем тестировать и в целом о предсказуемости того, что мы выкладываем.
Критерии (% релизов, которые привели к сбою):
отлично: <5%;
хорошо: <10%;
средне: <15%;
плохо: >15%.
4) Скорость восстановления (Mean Time To Recovery)
Показывает, как быстро мы поднимаем прод, если он сломался (упал, пришёл DDOS, выключились сервера). А ещё, умеем ли мы определять и измерять сбои. Упавшим продомом считается или факт того, что существенная часть системы недоступна, или коммит с hotfix'ом.
Критерии (как быстро поднимаем прод):
отлично: меньше часа;
хорошо: меньше дня;
средне: меньше дня;
плохо: больше дня.
Когда это нужно?
Для себя я выделил три критерия, когда эти метрики имеет смысл считать:
Когда есть конкретный продукт в активной стадии развития с постоянной командой хотя бы из 3-5 разработчиков. Т.е. это не что-то, что получает несколько фич в месяц или находится в стадии активного саппорта.
Когда компания большая, в которой появилось много команд с продуктами и нужно выстроить хоть какое-то понимание в среднем по компании. Вот тут, кстати, важно не начать погоню за метриками, т.к. все внутренние проекты живут в своём темпе. Нельзя выставить одинаковые метрики всем поголовно в качестве KPI.
Когда СТО\CIO нужны хоть какие-то метрики для отчётности. Чтобы объяснить инвесторам или нетехнической части C level'a, что в компании или команде хороший DevOps процесс (или, наоборот, плохой).
DORA метрики измеряются через GitLab или почти любую другую систему CI \ CD. GitLab умеет считать всё это из коробки. За исключением, наверное, падения прода (что тоже можно добавить вручную или вебхуками \ alert manager'ами).
---
Мой Telegram канал про разработку.
Мой open source проект для бекапа PostgreSQL - GitHub.
«Введение в управление проектами внедрения ERP-систем» А. Э. Бобровников (2-е издание) - обзор книги.
Ссылка на книгу на сайте фирмы 1С.
ERP-проектов на базе 1С всё больше, так что упомянуть это свежевышедшее издание книги не будет лишним.
Автор вроде бы опытный методист, теорией не перегружает, говорит на языке бизнеса. В книге по верхам собрано всё: от оценки сроков и бюджета до управления конфликтами и рисками. Акцент сделан на практику внедрения ERP на платформе «1С:ERP».
ЦА книги - это заказчик системы. А поскольку ассоциация 1С с продуктами для регламентированного учета всё ещё актуальнее других, отдельная глава посвящена тому, чем ERP-система отличается от системы для бухучёта (и почему она такая дорогая🌚).
Дальше - про стартовый этап проекта:
про функциональные требования и их сбор, у кого и как собирать, в каком формате
про выбор подрядчика (тендер) и этапы RFI, RFP, RFQ (если кто не знал, что это)
про fit-gap-анализ (в среде 1С это зовут еще выявлением функциональных разрывов)
и об оценке IT-инфраструктуры, включая нагрузочное тестирование, и расчет окупаемости.
Сам процесс внедрения может идти по принятым подходам (PMBOK, ISO, ГОСТ 34, Agile), а может и по фирменным методикам 1С (ТБР и т.д.). Стандартная модель - каскадная: инициация → анализ → проектирование → разработка → тестирование → ввод в эксплуатацию. Акцент на важности реинжиниринга бизнес-процессов (чтобы не автоматизировать хаос).
Отдельная глава - про стороны проекта внедрения. Команда исполнителя (внедренцы, методисты, разработчики), рабочая группа заказчика (ключевые пользователи), управляющий комитет (топы, принимающие решения).Само собой, говорится про важность мотивации, коммуникации и командообразования — иначе всё развалится.
Документация - тут всё очень кратко, в основном про использование бизнес-нотаций (IDEF0, BPMN, EPC) и прототипирование.
Говоря про сроки и бюджет, автор касается методов оценок (аналогия, экспертная, PERT, «сверху вниз» и «снизу вверх») и вспоминает классику - «мифический человеко-час», ошибки планирования, скрытые доработки. Отдельная глава - про управление рисками, про типовые риски (текучка кадров, ошибки ТЗ, сопротивление пользователей), управление|борьбу с ними.
По разработке и вводу в эксплуатацию - акценты на использовании нескольких контуров или баз (тестовая, рабочая и даже “грязевая” для экспериментов), и конечно же, на важности обучения пользователей и сбору обратной связи
Ну и “жизнь после смерти” - собственно, перевод проекта на стадию поддержки и сопровождения, поддержка пользователей и развитие системы.
Из интересного: второе издание книги оказалось стереотипным, т.е. перепечаткой с первого издания 2021 года. Конечно, хотелось бы обновлений - уж столько поменялось и в самих ИС, и в российском контексте их внедрения, - но, похоже, что у фирмы 1С всё хорошо и без этого и книга - своего рода стандарт.
Кому рекомендую: прежде всего, тем, кто готовится на роль ПМа в проектах 1С, особенно идущим на собесы, - идеальный конспект идеального внедрения (пусть его и не существует). Особенно в сочетании с одностраничными планами (приложил пример, который лично мне нравится больше других). Ну и тем, кто хочет слегка систематизировать проектный опыт.
Обзоры и дайджесты по проектному управлению - на нашем канале.
Что делать, если ваш проект все ненавидят?
В новом выпуске «Свободного слота» разбираемся, как пробивать непопулярные решения и объяснять их команде без потерь. Гость сегодняшнего эпизода — Сергей Щербинин, CEO Faust Consulting, основатель сообщества «Безвотэтоговсего». Вместе с ведущими Сашей Прокшиной и Сашей Афёновым обсуждаем:
что такое принцип ПВО;
как не продать душу дьяволу ради результата;
как заставить себя и команду делать то, что не хочется, но очень надо.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Иконка WhatsApp* на сайте: почему цвет фона лучше не менять?
Я сознательно убрал логотип WhatsApp* с сайта своей адвокатской практики. Это было единственное изменение в предложенном макете дизайна.
Иконка WhatsApp* располагалась почти на всех страницах сайта: "Главная", "Контакты", "Адвокат" и так далее. Потенциальный клиент мог кликнуть по иконке и создать чат со мной.
Но был нюанс - мой веб-дизайнер представил иконку WhatsApp*, заменив на ней фон.
Изобразительный товарный знак WhatsApp* известен цветовым сочетанием белого, серого и зеленого. На моем же сайте использованы другие основные цвета: синий, желтый и белый.
Веб-дизайнер отрисовал иконку WhatsApp* в цветах моего сайта. Получилось стильно, но рискованно. Почему?
В самом размещении логотипа WhatsApp* на сайте нет нарушения интеллектуальных прав правообладателя товарного знака - ВотсАпп ЛЛК (Калифорния, США). Тому есть простое объяснение.
Товарный знак нужен исключительно для индивидуализации конкретных товаров. Потребитель видит товар и связывает его с конкретным производителем.
Например, вы видите сайт с именем "WhatsApp*" в доменной зоне ".com" и понимаете: здесь предлагаются к продаже товары правообладателя этого товарного знака.
В моем случае логотип WhatsApp* на сайте не предназначен для индивидуализации моих услуг под брендом "WhatsApp*". Логотип лишь информирует о том, что клик по нему переведет пользователя сайта в чат с адвокатом - владельцем сайта.
Чисто информационная функция. Как следствие - изображение логотипа занимает незначительное место на экране сайта либо помещается в один ряд с иконками иных способов связи: e-mail, телефон и так далее.
Другое дело - возможность нарушения авторских прав:
1. Картинка товарного знака WhatsApp* кем-то нарисована.
Значит, есть автор произведения искусства. И у него есть право на единоличное использование картинки, в том числе в сети "Интернет".
2. Автор картинки передал интеллектуальные права на нее компании - владельцу товарного знака WhatsApp*. И компания запретила менять цвет в логотипе.
Об этом я узнал из Условий предоставления услуг WhatsApp*: пользователю разрешено использовать логотип с учетом Руководства по фирменному стилю WhatsApp*.
В Руководстве отсутствует разрешение менять фирменные цвета. Более того, в разделе "Вопросы-ответы" дан прямой запрет на изменение цвета в логотипе.
3. Я рискую получить иск о нарушении исключительного права на произведение искусства.
Логотип WhatsApp* зарегистрирован в России, что позволяет его владельцу обратиться с иском в суд. Основание - переработка логотипа без разрешения владельца и размещение переработанного произведения в сети "Интернет".
Поэтому вы не найдете на моем сайте иконку WhatsApp*: ее фирменный стиль выбивается из моего стиля, а изменение стиля WhatsApp* незаконно.
Поговорите с вашим адвокатом. Он предложит вариант оформления на сайте кнопки, которая ведет на чат в мессенджере WhatsApp*.
Узнать мой вариант решения можно, перейдя на сайт моей адвокатской практики. Ссылка в профиле.
Мысли вслух: при желании можно оспорить сам факт создания логотипа, ведь произведение должно носить творческий характер. Но есть ли творчество в том, чтобы на зеленом фоне круга поместить телефонную трубку?
* Деятельность компании Meta Platforms Inc. (Facebook и Instagram) на территории РФ запрещена.
Гендиректор OpenAI Сэм Альтман признал, что на фондовом рынке вокруг ИИ образовался финансовый пузырь с небольшими стартапами, который может скоро лопнуть.
На вопрос о том, не чересчур ли много энтузиазма инвесторы проявляют к технологии, Альтман ответил: «По моему мнению, да».
Гендиректор OpenAI сравнил реакцию рынка на ИИ с пузырём доткомов в 1990-х, который лопнул в 2000 году и привёл к краху интернет‑стартапов с раздутыми оценками. «Когда образуются пузыри, умные люди становятся крайне эмоциональны из‑за крупицы правды. Если посмотреть на большинство пузырей прошлого, например технологический пузырь, у него была реальная основа. Технологии действительно были важны. Интернет был настоящим прорывом. Люди стали слишком эмоциональны», — отметил Альтман.
Глава OpenAI считает «безумным» то, что некоторые ИИ‑стартапы «с тремя людьми и одной идеей» получают финансирование при баснословных оценках. «Это не рациональное поведение. Думаю, кто‑то обожжётся», — сказал глава OpenAI.
За последний год стартапы нескольких экс‑топов OpenAI — Safe Superintelligence Ильи Суцкевера и Thinking Machines Миры Мурати — получили миллиарды долларов инвестиций. «Кто‑то потеряет феноменальные суммы денег. Мы не знаем, кто это будет, но многие люди заработают феноменальное количество денег. Могу ошибаться, но мне кажется, что в целом экономика от этого сильно выиграет», — сказал Альтман. Он уверен, что OpenAI в любом случае переживёт пузырь.
Нужно срочно тупеть!
На управленческих курсах часто приводят подобную картинку, которая показывает, что чем дальше человек становится управленцем, тем меньше он становится специалистом.
То есть, с ростом управленческих навыков - Soft Skills, «проседают» технические навыки - Hard Skills. И это правда, с этим спорить я и не собираюсь. Но, в некоторых головах причинно-следственная связь срабатывает наоборот: «чтобы расти как управленец нужно срочно тупеть!».
Причем в этой среде наблюдается натуральное соревнование насколько ты отупел:
-«Я не технарь, я в этом не понимаю!»
-«А я еще больше не технарь, я в этом не понимаю еще больше! Ха-ха!»
А ведь раньше эти персонажи были, в общем-то, неплохими техническими специалистами.
Что интересно, там, где причинно-следственная связь между hard-soft skills не перевёрнута с ног на голову, даже среди управленцев высокого уровня много хороших специалистов, отлично разбирающихся в том, чем они управляют. И это не только на уровне IT-директоров, а даже на уровне вице-президентов огромных холдингов.
И дальше происходит следующая вещь: формируется круг общения «близких по духу». Это естественное состояние человека, окружать себя людьми со схожими взглядами, менталитетом и ценностями. Так вот, в этот круг отлично вписываются те, кто был изначально тупым! И не то что бы они делали это специально, нет. Тут наблюдается синдром товарища Даннинга-Крюггера не в виде привычной «дразнилки», а как реальный диагноз. Тупой просто не понимает, что он тупой. Потому что тупой.
И вот тут с приходом ИИ произошла некоторая синергия. Если раньше такой персонаж достаточно быстро отсеивался – набор случайных фраз "на тему" и "google-знания" заканчивались при первой же серьезной "проверке боем", то сейчас при помощи ИИ этими персонажами генерируются "мысли", очень похожие на осмысленные. Почти неотличимые. В которых нельзя четко сказать, что "вот здесь ошибка", но при попытке осознать мысль целиком получается чушь. Такая связка: управленец, сознательно отключивший свои Hard-скилы + "дурак с ИИ" в итоге приводит к деградации всей системы.
Но позвольте, а как же тогда реальное дело, там же это быстро выявится?
А тут всё просто – реальных дел… нет в контролируемых параметрах! Ни одного проекта и контракта за три года? Клиенты разбежались, репутация упала под плинтус? Да кого это интересует, этот вопрос даже не поднимается.
Показателем всего становится то, что лучше всего видно и просто измерить – шум. Самая заметная обезьяна в стае – не самая умная, а самая визгливая.
Попытка вернуть контекст в практическое русло тут же называется «токсичностью» и отсутствием Positive thinking. В лучшем случае – «душнотой».
Законный вопрос – но можно же показать, доказать, обосновать что вот это сгенерированное связкой дурак+ИИ – чушь.
Да, можно. Но тут два момента:
1. Эта чушь уже оттранслировалась наружу. «В этой клинике сердечо-сосудистой хирургии нам предложили покупать их циркониевые браслеты» 8-O. Вы второй раз обратитесь в такую клинику?
2. Это занимает чудовищное количество времени и сил. Просто указать на ошибку недостаточно: «жи-ши пиши с буквой И». Будут многочасовые споры с контр-аргументами «А я вот в твиттере писал жЫзнь и всё было отлично! И знакомые одноклассники так писали!». И это при том, что цель – написать научный труд. Вместо сосредоточения на науке приходится объяснять, что совать пальцы в розетку – плохая идея.
Но оно же продолжает жить и двигаться? Да, у любого достаточно крупного тела большая инерция, нет такой точки перелома "было-стало". Изменения не появляются в какой-то момент, а прорастают незаметно.
Так и здесь: Бежало. Шло. Замедлилось. Остановилось. Сдохло.
Выживут сохранившие баланс Hard и Soft.
Фиксируем следы на сайте нарушителя: 5 способов
Зафиксировать следы - первое, что нужно сделать после обнаружения нарушения ваших интеллектуальных прав.
Обычно такая фиксация проводится на веб-сайте виновника владельцем интеллектуальной собственности.
Ниже даны пять способов фиксации нарушения, которые суды принимают:
1. Самозащита. Вы определяете веб-сайт нарушителя, выбираете его страницы или их отдельные блоки, делаете снимки экранов.
Используете сервисы, встроенные в систему вашего компьютера или смартфона. Например, сервис работы со скриншотами в браузере Яндекса.
2. Автофиксация. Вам доступны специальные веб-сервисы для автоматической фиксации данных на сайте нарушителя.
Например, программный комплекс "Вебджастис". Его алгоритм собирает пакет сведений о сайте и условиях его работы, делает снимки экранов. И передает вам документ в формате pdf.
3. Нотариальный осмотр. Когда-то единственный способ закрепления следов. По вашей инициативе нотариус описывает сайт нарушителя и делает нужные скриншоты.
4. Осмотр правоохранителей. Например, следователь может осмотреть сайт в ходе проверки вашего сообщения о преступлении.
Копию протокола осмотра по запросу суда можно будет вовлечь в арбитражный процесс по нарушению интеллектуальных прав.
5. Адвокатский осмотр. С помощью адвокаты вы выбираете веб-ресурс для осмотра. После чего адвокат фиксирует условия осмотра и содержимое страниц сайта, передает вам сделанные скриншоты.
Поговорите с вашим адвокатом. Он поможет выбрать способ с учетом конкретной ситуации.
Если забыл какой-либо из способов фиксации, сообщите в комментариях. Приму с благодарностью.
