Я расскажу вам о своем опыте тимлида командой разработки в крупном банке, где старые управленческие привычки иногда брали верх над здравым смыслом. Это субъективная точка зрения на реальную ситуацию, где я — Д«Артаньян, а все остальные — редиски.
Сначала планировал зайти в 1С — устроился в 2014 году помощником программиста. Четыре года обновлял базы, ничего сложнее не давали. Зато на работе было много свободного времени.
Начал изучать PHP и Java — хотел попробовать бэкенд. Ходил на собеседования, но в 2016-2017 порог входа оказался высоким. Нужны были алгоритмы, профильное хорошее образование, глубокие знания. Таким самоучкам, как я, путь был заказан.
Кто-то подсказал — во фронтенде порог входа ниже. Сел изучать JavaScript по YouTube. Сделал тестовый проект — игру в домино, где костяшки раскидываются по столу и играют несколько игроков.
Мы решили встроить ИИ в систему управления проектами и посмотреть, что из этого выйдет. Спойлер: получилось лучше, чем мы ожидали.
Сегодня речь пойдёт о том, как превратить приблизительные оценки сроков выполнения задач в надёжные прогнозы, и о том, как рассказывать об этих прогнозах другим.
Оценка сроков выполнения задач — это важное дело. Но, в то же время, подобные оценки доставляют массу неприятных эмоций множеству инженеров и программистов. Оценки сроков являются источником напряжения, которое возникает между командами разработчиков и всеми теми, кто так или иначе с ними взаимодействует. Это — менеджеры, другие отделы компаний, клиенты.
Всё дело в том, что почти все до сих пор неправильно рассказывают другим об этих оценках.
Привет, Хабр! Меня зовут Анастасия Типакова, я руковожу группой развития технологий информационного моделирования инженерного направления в ПИК.
Сегодня расскажу подробнее про наш продукт ИОС (инженерное оборудование и сети) из экосистемы ПИК. Полное описание экосистемы можно найти в статье «Экосистема ПИК. История формирования».
Всё началось в далёком 2018 году, когда ПИК начал формировать продуктовую модель в Дирекции автоматизации проектного блока. Постепенно стало ясно, что готовые инструменты и сервисы прекрасно адаптируются под продуктовую модель. Так у нас появилась целая линейка продуктов: Family Manager, BIM Inspector, PikTools, Робот R2, BIM Data Service и PIK СheckUP.
Семь специалистов, семь Excel‑таблиц, и десятки требований регуляторов, которые обновляются со скоростью света.Каждая проверка — это гонка с дедлайном, хаос в переписках и отчаяние в глазах команды. Дошло до того, что отпуск одного сотрудника мог парализовать работу всей службы ИБ. Перемены не приходят в одночасье, обычно осознание того, что нужно что‑то менять приходит слишком поздно — а именно, после первого серьезного инцидента, когда урон уже нанесен.
Когда мы думаем об информационной безопасности в банках, чаще всего представляется гигантская организация с отдельным ситуационным центром, огромным штатом SOC‑аналитиков, миллионами в бюджете, заложенными на киберзащиту и командой проектных менеджеров, которые годами тестируют и внедряют системы и подходы. Но реальность не всегда является такой.
Сотни небольших банков в России и странах СНГ работают в совершенно иных условиях: команда ИБ — это несколько специалистов, бюджет — строго ограничен, а требования регуляторов — те же самые, что и для топ-10 игроков рынка.
Наш кейс — про один такой небольшой банк в России. Всего семь сотрудников в службе ИБ. И при этом — ГОСТ 57580, методические рекомендации 3/8/12, 72 форма отчетности и десятки других обязательных требований, которым нужно соответствовать.
Задали вопрос — получили ответ прямо в ChatGPT, а сайт-первоисточник так и не открыли. Это феномен «нулевого клика». Интернет превращается в высокоуровневый API, а мы — в его пользователей.
И как любая новая абстракция в технологиях, этот сдвиг открывает не только удобство, но и «утечки», а бизнес теряет деньги и клики.
Зачем вообще нужна дизайн-система? В первую очередь, для стабилизации и ускорения проектирования с разработкой. Затем — для унификации пользовательского опыта. Идея хорошая, однако иногда вместо этого мы просто получаем барьер на каждом шаге. Перекрасить кнопку? Согласование. Новый элемент или паттерн? Дизайн-комитет. А/В-тест? Сначала в ДС.
Команда учится делать не «лучше», а «правильнее». Развитие продукта замирает, потому что «в системе так не принято». Это и есть ДС-тюрьма: удобно сторожам, плохо заключённым.
Эта заметка развернулась из комментария к статье: Таски есть, системы нет.
С моей точки зрения, заглавие разсматриваемой стати верно. Однако в содержании перечислены проблемы-следствия, без разкрытия ключевой затронутой проблемы.
В заметке я постараюсь выйти на эту ключевую проблему и затронуть вопросы вида:
Из чего такая система должна произрастать? Какие к ней требования? Есть ли примеры?
В карьере каждого специалиста наступает момент, когда он размышляет, стоит ли ему уйти в свой бизнес или всё же лучше остаться в найме. Один из самых простых и очевидных способов начать своё дело – это открыть агентство.
В этой статье я расскажу, о чём важно знать, прежде чем начать этот бизнес, какие сложности вас ждут и почему вы не сможете управлять командой из 20-30 человек без продвинутой аналитики.
Порой разработка нового продукта, автоматизация существующего процесса выглядит, как работа хирурга, который провел сложную операцию: в моменте избавил человека от серьезной проблемы, а то и вовсе спас жизнь. И на этом, как правило, история заканчивается. Однако после каждой операции есть еще одна очень важная стадия, о которой почему‑то не принято говорить — это реабилитация. И от того, как она пройдет, зависит работоспособность органов и качество жизни.
В IT‑разработке тоже есть такая стадия — это поддержка того, чем осчастливили заказчиков. Если ее упустить, то даже идеально проведенная «операция» может закончиться осложнениями. Поэтому для аналитика понимание этой стадии не менее важно, чем участие в создании нового продукта.
Всем привет! Меня зовут Роман, я руковожу разработкой. Когда‑то начинал разработчиком, потом тимлид, сейчас управляю лидами.
В моём багаже опыта — работа работа в интеграторе, потом в небольшой компании из сферы SMS‑маркетинга, череда позиций в in‑house разработке в разных отраслях. А сейчас я снова в айтишечке, в заказной разработке.
И вот что забавно: на протяжении всей карьеры меня преследует один и тот же вопрос — как правильно поставить задачу и как отследить реальное состояние разрабатываемой системы.
Казалось бы, инструментов хватает: Jira, YouTrack, Trello, GitLab, Confluence и ещё десятки. Но если копнуть глубже, становится понятно: каждый из них решает только кусочек головоломки. Целостной картины всё равно нет. Она появляется только в голове после погружения, но и тут засада — голов в проекте много, и у каждой своя картинка.
Получается парадокс: мы для других системы строим, а своей нормальной системы у нас всё так же нет. Думаю, многие коллеги узнают себя.
Я выделил пять основных проблем, которые должна решать такая система. Сразу скажу, что америку я не открыл. Хочу разобраться: чего же не хватает для организации разработки без головной боли по поводу тасок.
Меня зовут Павел Крамин. Я много лет занимаюсь коммерческой разработкой для маркетинга и продаж на российском рынке.
В статье разберём, как производителю или импортёру автоматизировать работу с дилерской сетью. Текст будет полезен владельцам продукта, менеджерам проектов и продуктовым аналитикам. Мы не будем углубляться в технические детали, а посмотрим на задачу глазами бизнеса.
Если у вас с руководителем полное взаимопонимание, вы киваете друг другу с полуслова и вообще обожаете свою работу — закройте эту статью и идите пить свой раф на кокосовом. Мы с остальными тут немного пострадаем. Расскажу, как мне удалось превратить душного начальника в персонального бустера производительности.
ИИ не заменяет бизнес-аналитика, при этом заменяет бизнес-аналитиков, которые не хотят или не могут адаптироваться. Он делает профессию сложнее, интереснее и стратегически важнее, вымывая из нее рутину.
Еще один инструмент для бизнес-аналитика (БА), как когда-то им были MS Visio или Jira. Это фундаментальный сдвиг, который меняет саму суть работы, ценность специалиста и структуру команд.
Одна из самых важных компетенций эффективного руководителя – это понимание своей зоны ответственности и не боязнь отдавать членам команды их зоны ответственности, то есть быть Взрослым и создавать команду Взрослых.
Поэтому, когда вы собрали свою команду, очень важно дать ей возможность максимально реализовать свой потенциал. Создать команду лидеров, то есть позволить сотрудникам брать на себя ответственность за отдельные вопросы бизнеса, стать Взрослыми. Распределенное лидерство – это как раз про это, не надо бояться большого количества лидеров в команде, чем больше лидеров, тем более самостоятельна и устойчива команда, при этом вас точно никто не подсидит, потому что все получают реализацию своих амбиций и способностей.
Для развития распределенного лидерства необходимо научиться основному инструменту эффективного руководителя - делегированию. Все знают о делегировании, но, к сожалению, либо боятся его использовать, либо используют неправильно.
Делегирование бывает двух видов, так как есть только два типа сотрудников, для которых его необходимо использовать.
Для новичков в какой-то задаче мы используем Делегирование Исполнения, когда ставим четкую цель, сами даем ресурсы и инструкцию, и проверяем выполнение каждого этапа.
И для опытных сотрудников в данной задаче используем Делегирование Управления, когда ставим цель и сроки, а ресурсы и варианты реализации сотрудник выбирает сам, контроль за выполнением лишь один раз в середине процесса и то в форме вопроса: «Как дела? Нужно ли что-то?»
Видите, все просто, правильно выбранная система делегирования позволяет одним сотрудникам развивать компетенции специалиста, а другая компетенции лидера.
Также, примером варианта реализации распределенного лидерства является холакратия и ее вариант Agile, когда мы используем разнообразие нашей команды и меняем роли ее участников и зоны их ответственности.
#лидер #управление #команда #руководитель
Вроде бы работа кипит, команда старается, вы делаете всё по процессам, но в ответ — постоянное ворчание, претензии и недовольство. «Почему вы не предупредили?», «Я думал, всё будет иначе!», «Это слишком долго и дорого».
Управление проектами с помощью канбан-метода — это не только стикеры с задачами, которые команда передвигает между этапами. Сегодня командам мало простой доски в офисе, чтобы визуализировать все бизнес-процессы. На смену приходят многофункциональные канбан-сервисы, которые точно отображают воркфлоу, а не только список задач.
Как выбрать инструмент, где будут не только канбан-доски для планирования задач, но и другие важные функции для комплексного управления проектами — разбираем в этой статье.
Продуктовые роли не появились из воздуха. Их не придумали с нуля бородатые дядьки в Долине или выглаженные воротнички из Купертино. Профессии Product/Project Owner/Manager выстраивались на протяжении почти столетия — и всё ради того, чтобы сейчас мы с вами плевались, читая вакансии на хедхантере. Кто главнее: PM или PO? Что должен делать проджект? И что ещё за AI PM и Data PM?
Давайте разбираться. И копнём аж до начала прошлого века.
В начале декабря 2008 года Tesla оказалась на грани банкротства, и тогда Илон Маск буквально спас компанию: он вложил в нее более $70 млн личных средств. Уже 24 декабря был заключен последний «Рождественский» раунд инвестиций, включая $50 млн от Daimler. Согласно Investopedia, именно «известность Маска и его крупные инвестиции сыграли решающую роль в формировании доверия и привлечении других инвесторов». Без публичного лица вроде Маска столь щедрая сделка в тот момент могла и не состояться.
