Даже правильно выбранная 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 человек, отметивших информативность и актуальность поднятых тем.
Я бережно нарезала видео докладов и собрала их в один пост, чтобы вы могли посмотреть то, что вам интересно. Надеюсь, будет полезно.
Работа на коротких проектах похожа на курортный роман. Встретились, события закрутились, на пике эмоций помахали друг другу рукой. Другое дело, если проект длится годами. Тогда совместная проектная команда проживает запал на старте, а потом проходит через несколько кризисов как настоящая семейная пара. В таких историях менеджеру проекта не получится только отслеживать «сделали/не сделали». С особым рвением ему нужно следить за тем, чтобы мотивация команды не сдувалась, а еще поддерживать репутацию коллег в глазах клиента. Как? Делюсь своим опытом.
