Управление разработкой *

Привет, Хабр! Мопед не мой я просто разместил объяву. (с) В этой статье я расскажу о процессах и ролях, которые придумали до меня и тут будет просто пересказ как оно было с моих слов. Я в IT 13 лет. Первый мой опыт управления командой был … в молодости в рейдах WoW где я был лидером рейда ака РЛ. В общем рейд это нападение на сильного монстра куда собирается много игроков вместе и РЛ их организует.  Сейчас я CTO стартапа Dish&Fork. Сейчас мы на стадии бета тестирования в Москве.  

Друзья, привет! Если у вас так же много разработчиков как у нас, то и им, возможно,  стало тесно стоять в очереди на deploy в монолите. А значит, вы можете решить перейти на микросервисную архитектуру и дать каждому игроку свой мяч каждой команде свой микросервис. 

Меня зовут Дмитрий Лукиянчук, и я руковожу отделом в IT-платформе СберМаркета. В этой статье я сделаю обзор инструментов, которые у нас есть сейчас, спустя 2,5 года, и какие задачи эти инструменты решают. Вы узнаете, что вам нужно будет сделать, если вы сами решите взяться за построение платформы, а если у вас уже есть своя платформа, то вам будет интересно найти 10 отличий в своей и нашей реализации.

Мы в Авито разработали свою внутреннюю платформу для разработчиков. Несмотря на то, что создание платформенного продукта — довольно затратная история, в итоге мы видим сплошные плюсы. Она растит скорость и качество разработки, делает системы стабильнее, помогает инженерам сосредоточиться на бизнес-задачах, а не на рутине. 

Наш опыт построения платформы мы постарались заложить во внешнее решение Plato, которое опирается на проверенные open-source решения.

О преимуществах платформы, процессах её разработки и сложностях в реализации — в этой статье.

В области разработки программного обеспечения и ИТ-операций внедрение практики DevOps стало переломным моментом. DevOps, объединяющий слова "разработка" и "эксплуатация", представляет собой целостный подход, в котором особое внимание уделяется сотрудничеству, автоматизации и постоянному совершенствованию на протяжении всего жизненного цикла разработки программного обеспечения. Давайте отправимся в комплексное путешествие по различным этапам жизненного цикла DevOps и поймем, как каждый из них способствует достижению эффективной доставки программного обеспечения

Данная статья расскажет о том что такое SysOps, какие навыки должны быть для работы в этой области, какую пользую она несёт для компаний и какие могут быть противоречия. В статье также приведены примеры применения SysOps и жизненный цикл.

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

Подготовили подборку статей на английском языке от beeline cloud, которые помогут разобраться в работе Kubernetes и взвесить все за и против с точки зрения его использования. В статье делимся инструментами, которые также пригодятся менеджерам.

Программируя в течение 20 лет, я очень часто слышал об архитектуре и архитекторах. При этом с архитектурой проектов работать приходилось постоянно, а живых архитекторов не видел никогда. 

Да, в командах всегда были сильные разработчики, которые следили за развитием отрасли, были жадными до новых технологий, языков программирования и баз данных. Несмотря на то что архитекторов в командах не было, книг по архитектуре хватало. IT-отрасль интенсивно трансформировалась под воздействием больших данных, docker-революции, восхождения облачных платформ. 

Разработчика всегда спрашивают: «Куда ты хочешь развиваться — в менеджмент или архитектуру?» Более того, я сам это делал множество раз :) Всегда складывалось впечатление, что на этой развилке работает только одна дорога — в менеджмент. 

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

Мы разрабатываем стартапы на аутсорсинге — и их в нашем портфолио накопилось уже больше 30.

Но не все из того, что мы когда-либо сделали, в итоге выстрелило: где-то вмешались непреодолимые силы, где-то перегорели или переругались фаундеры, а где-то идея оказалась далеко не такой перспективной и масштабируемой, как могло показаться на старте.

Хочу рассказать о 5 интересных проектах, которые так и не взлетели.

Собрали комментарии специалистов из разных компаний и агентств. Это выжимка из третьего выпуска НЕОЧПОП про грейды. Кому нравится смотреть и слушать, просим на Ютуб.

Каждый из нас знает и лично сталкивался с "эффективными менеджерами": они в гонке за сиюминутной и порой даже мнимой выгодой для компании принимает решения, которые приводят к потерям. В том числе гонит своих подопечных на постоянные переработки, при этом постоянно измененяет правила игры, нарушает обещания и то и напрямую обманывает и так далее.

К сожалению, в управлении людьми слишком много не только таких менеджеров, но и самых разных мифов, заблуждений и управленческих ошибок, которые и хочется разобрать в этой публикации.

Любая работа начинается с планирования. И чем детализированнее вы составляете план, тем удобнее этому плану следовать. Мы собрали собственный опыт ошибок и составили крепкую базу для начинающих аналитиков, разработчиков, тестировщиков и прочих котиков, которые уже вошли в айти, но скромно топчутся на пороге. Вот им мы хотим объяснить, почему планирование - это важно.

В этой статье, я хотел бы обратить внимание на проблемы во взаимодействии, коммуникации между участниками команды разработки. Определить причины, предложить решение. Также в конце статьи вы можете найти список технических вопросов, ответы на которые помогут улучшить коммуникацию между отделами (арт и тех) с самого старта проекта.

Привет, меня зовут Антон Фокин, я CEO студии QTIM, занимаемся заказной разработкой. Сайты, приложения, цифровые сервисы, вот это вот всё. Статью мне помогал писать Артём Трушин, наш CPO. Расскажем, как мы выкинули написание ТЗ из наших процессов и сократили среднее время на разработку проектов в 4 раза.

Miro недавно опубликовали в своём блоге статью о том, как при помощи некоторых своих досок улучшить взаимодействие в кросс-функциональной команде. Показалось, что статья может быть полезной для более широкого круга читателей, поэтому решила её перевести.

Перевод достаточно свободный, но сохраняет суть. При переводе ни один ИИ не пострадал.

Сказать начистоту, работа в кросс-функциональной команде – дело непростое. Когда людям из разных отделов приходится работать в одной команде, можно столкнуться с плохой коммуникацией, недоверием друг к другу и рассогласованностью действий. Если вы тимлид или менеджер проекта, то, по большей части, вы и несёте ответственность за то, чтобы все были на одной волне. Начните с предложенных ниже шаблонов и советов по их применению, чтобы сплотить команду. Они вряд ли решат все ваши проблемы, но помогут заложить фундамент для будущего сотрудничества, основанного на духе товарищества.

Привет! Я Юля, менеджер продукта в Тинькофф Кассе. Мы делаем интернет-эквайринг для бизнеса, и в разработке продукта участвуют 30 команд. При создании новой фичи какие-то команды могут действовать обособленно, но это редкость. В большинстве случаев командам при разработке нужна помощь друг друга. Расскажу, как у нас получилось сделать так, чтобы не было очередей из команд.

Обычное дело — на этапе обсуждения будущего проекта студия выясняет, что на стороне заказчика нет лица, принимающего решение. Точнее он есть, но до него не добраться. Вместо него дела ведет доверенный менеджер. Брать ответственность за принятие окончательного решения он не может, но и выхода на ЛПР не дает.

Проблема в том, что это не выгодно никому — ни ЛПРу, ни менеджеру, ни подрядчику.

В статье расскажем, каких ошибок избежит бизнес, если в разработке продукта будет участвовать лицо, принимающее решение. 

Привет! Меня зовут Андрей, я head of platform в финансовом маркетплейсе Банки.ру. 

Для создания своих продуктов мы применяем микросервисный подход. Он помогает нам ускорить разработку и делает ее гибкой и управляемой. Но как в любом подходе, у него есть темная сторона, проявление которой может создать кучу неприятностей и осложнить работу над проектом. Сегодня хочу поговорить об одном из таких аспектов — о сервисах-«сиротах» (так мы их ласково называем в Банки.ру, поэтому дальше кавычки ставить не буду).

Эта статья – оптимистичное и структурированное продолжение моего доклада на ту же тему, с которым я выступал в 2018 году. Текстовая версия есть на Хабре.

Годы взаимодействия с разномастными сиротами помогли их классифицировать, поэтому захотелось уделить больше внимания тому, какие сироты бывают, чем они опасны или хороши (такое тоже случается), каких нужно возвращать в семью, а от каких отказываться. Чтобы было зрелищнее и веселее, использовал образы и иллюстрации из мира «Гарри Поттера» в целом и «Фантастических тварей» в частности, прошу понять и простить. Права на изображения незыблемо принадлежат братьям Уорнер – и всё такое.