Недавно мы провели свой первый митап для менеджеров продукта. Спикеры из Авито рассказали на нём о нашей менеджерской линейке, необходимых продакту компетенциях и устройстве дискавери-команд. А спикер Dodo Brands поделился, как они синхронизируют бизнес-цели и IT.
В посте — видеозаписи выступлений с таймкодами и ссылки на презентации.
Даже правильно выбранная TМS нуждается в кастомизации. Я, Марина Каприз, занимаю должность заместителя руководителя Блока обеспечения качества и выпуска изменений ПО в ООО «РСХБ-Интех», расскажу, как в Россельхозбанке происходил переход к автоматизированной системе управления тестированием.
Всем привет. Меня зовут Божок Анна. Я фанатка Notion и это моя первая статья.
Хочу вам рассказать про новую функцию в программе. А именно сквозной или синхронизированный блок.
И так же поделюсь тремя вариантами его использования.
По мере роста популярности науки о данных и её определения как профессии возникла идея, что Data Science автоматизируема, потому что автоматизируется множество процессов: сравнение моделей, визуализация, очистка данных; но на других, ключевых этапах дата-сайентисты — самые ценные специалисты. К старту флагманского курса о Data Science делимся переводом статьи Senior Data Scientist в Favor Delivery о том, почему дата-сайентиста нельзя заменить машиной.
Мы уже писали о проектах из сферы здоровья, образования, экологии и многих других. Сегодня представляем подборку решений от участников Архипелага 2121, посвященных развитию водного транспорта и изучению мирового океана.
В этой статье я расскажу о своем опыте внедрения Agile на DS проекте с нуля. Я расскажу по шагам что мы с командой пробовали использовать, к чему это привело, какие ошибки допускали и как мы в итоге пришли к стабильному, простому и понятному процессу разработки.
Контекст проекта и немного введения
Проект, с которым мне пришлось работать связан с определением объектов по камерам наблюдения на физических объектах (ресторанах). Нашей основной задачей было создание системы определения объектов и вывода необходимой информации на дашборде, а также мы осуществляли развертывание системы на объектах (более 1500) и поддержку пользователей.
Наша команда состояла из Data Science и Computer Vision специалистов, было несколько QA, один Frontend Developer и один Backend Developer. Я выступал в роли Project Manager.
Когда я только приступил к работе над проектом, там не было никакой документации, плана, отчетности и т.д. Все делалось на словах, что-то немного трекалось в Trello, это был тот еще хаос.
В этой статье я расскажу больше о процессе разработки. На проекте также был очень сложный процесс развертывания и поддержки пользователей. Этих процессов касаться в этой статье я не буду.
Этап 1. Начало внедрения Agile.
В самом начале моей основной целью было понять что вообще необходимо сделать, к какому сроку, кто чем занимается и что вообще есть сейчас.
В интернете я наткнулся на целую кучу различных статей о том, как выстраивать процессы в DS, но у всех были разные мнения: кто-то советовал Kanban, кто-то Scrum, кто-то описывал свои методики, но ничего общего я не нашел, не было ничего, что можно применить к любому проекту такого рода. Однако, самым ценным было знакомство с концепцией CRISP-DM.
Сейчас явно прослеживается тенденция на очеловечивание сухих интерфейсов. Это говорит о том, что меняется подход к разработке IT-продуктов даже в тех компаниях, которые считались консервативными. Клиент повсеместно стал более требователен и разборчив. Что бы оставаться конкурентоспособными, компаниям важно ориентироваться на пользователя, его нужды и пожелания. Меня зовут Дмитрий Бохан, в ПГК руковожу проектом «Личный кабинет клиента». Недавно на одном вебинаре рассказал о том, как превратить сухую бизнес-идею в «живой» интерфейс. Хочу поделиться и с вами. Надеюсь, этот опыт будет полезен.
По какому принципу бизнес выбирает, что автоматизировать? Всегда есть минимум два вектора, на которые можно опереться: это либо повышение лояльности наших клиентов, либо сокращение костов. Личный кабинет клиента – повсеместное явление, в том числе в транспортных компаниях, которые сейчас относятся к активно развивающейся «в цифру» отрасли. В нашем случае от бизнеса прозвучал заказ на качественный Личный кабинет клиента ПГК. Даже в такой консервативной отрасли, как жд перевозки, клиенты хотели приложение, которое по удобству могло бы сравниться с сервисами, привычными нам в сегменте b2c.
На старте проекта для каждой команды важно определиться, кто заинтересован в проекте. В нашем случае заказчиком внутри компании выступил исполнительный директор. Но ведь не будешь по каждому вопросу бегать к нему. Поэтому на начальном этапе важно сформировать матрицу стейкхо́лдеров (англ. stakeholder) с указанием уровней ответственности. То есть создать перечень людей, которые будут нести ответственность за принятые решения.
Все менеджеры борются за тонкий баланс между выполнением краткосрочных задач и инвестированием времени в деятельность с долгосрочными перспективами.
Результат, который видно сразу, может дать чувство удовлетворения в текущий момент, но вскоре это чувство исчезнет и нужно будет еще больше энергии, чтобы идти в ногу с темпами роста и масштабами компании. Чрезмерное сосредоточение внимания на прогрессе в краткосрочной перспективе в итоге замедлит работу менеджера в долгосрочной.
Энергия, потраченная на развитие бизнеса, позволит вам достичь каких-то результатов, но та же энергия, вложенная в рост людей, может привести вас к отличным результатам.
Самый плохой разработчик — тот, который всё делает по ТЗ. А самый лучший код — не написанный.
«Моя задача — писать код, я разработчик!» — да, это очень удобная позиция. Но людям, которые не только программируют, но ещё и общаются с коллегами, организуют собственную работу и понимают предметную область, платят больше. Потому что они приносят бизнесу больше пользы. Разработчики, которых надо микроменеджерить, чтобы они делали свою работу, никому не нужны.
Основная обязанность разработчика — это решить проблему. Не написать код, не отдать задачу на тестирование, а решить проблему. Писать код по спецификациям может любой дурак (на самом деле тоже нет). А вот решать проблемы — нет. Для этого надо думать и брать на себя ответственность.
Это история не про любовь, мир, жвачку и миссию компании, а про простую способность сделать свою работу так, чтобы она была сделана хорошо. И да, для этого разработчик должен не только уметь программировать, но и уметь общаться с другими людьми, уметь доносить свои мысли, уточнять и понимать, что вообще происходит. То есть уметь договариваться. Да, разработчик должен уметь организовывать свою работу: раскладывать проблему на задачи. Ещё он должен интересоваться продуктом (проектом). Не потому что разработчик так его любит, и не потому, что этого требует Agile, а потому, что живой интерес к продукту и понимание его ценности увеличивает качество решений и стоимость разработчика на рынке. Знание предметной области и её ограничений — первейшее требование для того, чтобы принять правильное техническое и архитектурное решение. И очевидно, что чем меньше руководитель тратит сил на управление сотрудником и чем больше получает результат, — то есть чем выше автономность сотрудника, его самостоятельность и беспроблемность, — тем он ценнее при прочих равных.
Только мы все привыкли к умному дому, как появилась новая идея — умный город! Представь, что есть большая добрая городская «Алиса», которая подскажет туристу, куда идти; коммунальным службам, где открылся люк и передаст властям, где не хватает зелени или освещения. Звучит интересно, не так ли?
Некоторые участники Архипелаг 2121 подготовили проекты для развития умных городов.
Как выбрать лучшую СЭД для компании? Кратко - никак, все СЭД одинаковые, но при выборе важно другое
Чтобы помочь ИТ-отделу ответить на вопрос «Как все-таки выбрать и внедрить СЭД в компании?», мы пообщались с экспертами из самых опытных компаний-интеграторов на российском рынке СЭД.
Когда-то давно в дебрях Интернета я случайно нарвался на матрицу компетенций программиста от Джозефа Сиджина, которая помогла мне правильно оценить свою стоимость на рынке труда и выработать пути по дальнейшему самосовершенствованию. Шло время, проекты в которых я участвовал, росли. Росли, росли и выросли до такого состояния, что в этих проектах потребовалось участие не только программистов, но и аналитиков. Помня положительный эффект от матрицы Д. Сиджина, в какой-то момент я решил найти такую же шкалу компетенций, но уже для аналитиков. И, что неудивительно, нашел.
Выдался у меня как-то на работе хороший год. Я сделал пару серьёзных проектов, за что получил существенную прибавку к окладу. Естественно, я захотел этот опыт повторить. Пришёл к директору и говорю – хочу +30%, готов стараться от всей души.
Тот почему-то обрадовался. Давай, говорит, всё-превсё автоматизируем в течение года, и будет тебе прибавка. Чтобы понять, кто такое «всё-превсё», мы собрали совещание всех отделов. Люди с радостью притащили хотелки, мы из сгруппировали в 13 проектов.
Увидев предстоящий объём работы, я, конечно, приуныл. А директор – наоборот. Когда все отделы ушли с совещания, он сказал: я тебе помогу. Ну, думаю, поможешь ты мне. Уже помог, спасибо.
Директор же сказал: я знаю, как тебе легко и быстро сделать все эти проекты. Ты, говорит, сам от себя офигеешь. Будем делать по-гибкому, в стиле эджайл.
Меня зовут Паша Мягков, я frontend tech lead в команде монетизации Учи.ру. Несколько месяцев назад рост команды и задач привел нас к тому, что привычные рабочие процессы перестали отвечать нашим потребностям. Болезнь роста затронула прозрачность разработки, планирование и workflow. В этой статье я расскажу, как в рамках одной быстро выросшей команды нам удалось наладить процессы.
С увеличением объема работы разработка становилась менее и менее прозрачной. Часть требований к большим фичам с множеством компонентов и зависимостей в микросервисной архитектуре просто терялась, из-за чего разработка затягивалась. Продолжать жить так дальше было нельзя, поэтому мы кардинально изменили подход к работе. Наше решение не претендует на уникальность, но именно оно помогло нам справиться с увеличившимся потоком входящих задач качественно и вовремя.
Привет, менеджер!
Сегодня я расскажу о самом простом плане работы с проектом от его начала до его завершения. Этот план отлично подойдет для новичков. Если вы еще не освоили Agile, не знаете всех инструментов и лучших практик, но проект сделать нужно, то эта статья для вас.
Совсем немного введения
При разработке нового продукта важно выяснить каким конкретным требованиям он должен соответствовать, необходимо продумать основные функции и интерфейс, а также некоторые важные детали реализации.
Как правило, до начала процесса разработки подготавливается описание основных, самых важных компонентов и достаточно поверхностно, некоторые детали могут быть описаны подробнее, при необходимости. Детализация требований происходит параллельно с процессом программирования и фиксируется, обычно, в ТЗ, а также в виде задач для команды. Такой подход позволяет на этапе инициации проекта достаточно быстро подготовить информацию по проекту, которую можно использовать в оценке проекта, а также дает большую гибкость в реализации проекта, так как требования имеют свойство меняться в процессе (закладываем на это время в оценке).
Итак, ниже я опишу материалы, которые необходимо подготовить для проекта, а также основные этапы работы над проектам от инициализации до запуска и что вам нужно делать на каждом из них.
Для полноценного проектирования и детализации требований продукта необходимо подготовить следующее...
Так вот, пользовательские истории! Несомненно, это один из основных столпов agile(гибкой)-разработки и необходимый инструмент для продакт-менеджера.
Одним из принципов agile-разработки является идея разбиения крупных разработок на более мелкие части, называемые историями. На пути к тому, чтобы стать ниндзя-мастером на позиции продакт-менеджера и приносить пользу клиентам с помощью своего продукта, вам придется заботиться о бэклоге и содержащихся в нем пользовательских историй.
Но что такое пользовательская история?
Чтобы ответить на этот вопрос, давайте разделим это понятие на части:
Как много статей в интернете от матерых скрам-мастеров и их историй успехов. Прям читаешь и завидно становится.
Историй много, а вот заметок, с какие трудностями они сталкивались - мало. Об эпичных и не очень провалах я вообще молчу - фрезировщик на заводе может по пальцам своей руки их посчитать.
Вот почему? Это же самое ценное и крутое пособие по тому, как реагировать на трудности и какие уроки выносить из своих фейлов! Как раз то, что не хватает еще зеленым начинающим скрам мастерам.
Когда я только стояла в начале пути неординарного и смелого скрам-мастера, где-то на уровне подсознания я понимала, что этот путь не будет безмятежной прогулкой по прекрасному саду, но и подумать не могла, что этот сад будет с разбросанными повсюду граблями. И я, конечно же, наступила на все.
У нас в компании 8 мобильных приложений и почти столько же мобильных команд. Конкретно наша работает с приложением для покупателей. Когда нас было немного, по 6-10 человек в iOS, Android и QA–командах, мы отлично справлялись с задачами. С ростом столкнулись с проблемой: чем больше у тимлида людей в подчинении, тем меньше он может уделить времени каждому, меньше времени имеет на погружение в задачи. В итоге качество управления команд начинало ухудшаться и с этим нужно было что-то делать
Решение мы нашли в распределении команд по стримам.
В этой статье расскажу как у нас организована работа для 30+ мобильных разработчиков и 14 QA: как мы планируем, делимся знаниями и что нам даёт этот подход.
Привет! Меня зовут Света Друзь, я деврел в Beeline Казахстан. Отвечаю за коммуникацию и развитие комьюнити внутри компании, постоянно ищу новые интересные темы, подготавливаю спикеров и курирую проведение внутренних и внешних ивентов.
В апреле 2021 года мы провели большую онлайн-конференцию для разработчиков, IT-менеджеров и BigData-специалистов. В конференции приняли участие почти 2 000 человек, отметивших информативность и актуальность поднятых тем.
Я бережно нарезала видео докладов и собрала их в один пост, чтобы вы могли посмотреть то, что вам интересно. Надеюсь, будет полезно.
