Привет! Я Лена, ИТ-лидер 1С в Moex. Хочу поделиться историей, как я внедрила ретро в своей команде, не знакомой с ней и какие инструменты для этого я использовала.

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

Продолжаю делиться личным опытом в планировании. Без воды, лирики и рерайтов. В статье перечислю инструменты которые прошли проверку временем и самое главное — ленью. Я отсеял всё лишнее и оставил только то, что действительно полезно и эффективно.

Расскажу, как работать с планированием на ежедневной основе — по сути, на какие кнопки я нажимаю (поговорим про софт), как провожу утро (та самая практика — книга «Магия утра», но в моей собственной интерпретации) и как я лично использую известные фреймворки:

— Getting Things Done, как основа процесса;

— Матрица Эйзенхауэра, как способ приоритизации;

— Метод «Съесть лягушку», как вспомогательный инструмент к Матрице Эйзенхауэра, потому что я всё‑таки ленивый и не всегда сам себе честно отвечаю, что действительно надо сделать в первую очередь.

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

Опуская множество НО, в целом, философия Agile (а никак иначе язык сказать не поворачивается) показала довольно неплохие результаты с точки зрения организации команд в других, околоайтишных направлениях.

И возник вопрос, возможно ли этот подход положить на понятный, последовательный и очевидный проект в области Охраны труда. Казалось бы, зачем? А затем, что помимо понятной и очевидной части есть совершенно непредсказуемая и многогранная - работа с Заказчиком, пользователями и экспертами.

Есть в Айти стандартные грейды: Джун, Мидл, Синьор.

И всех руководителей ИТ проектов тоже можно разложить по этим уровням. Мне это помогает четче формулировать требования к сотруднику и куда ему дальше расти. Вам может помочь понять, что надо подтянуть, чтобы достичь нужного уровня, какие есть перспективы дальше. А если вы ищете РП – можете использовать для описания работы в вакансии 😊

Непричеметр (он же дисклеймер): эта статья – мое личное мнение, основанное на большом числе собеседований, которые я провел и прошел (суммарно больше 400). У меня нет статистических данных, я не проводил опросы и так далее. Зато почти каждый год на протяжении 20 лет я ходил по собеседованиям, последние 15 лет я собеседовал РП, а последние три года я непрерывно искал аналитиков и менеджеров, так что сформулировал четкие критерии отбора, которыми и хочу поделиться в статье ниже.

Большинство предприятий среднего и крупного бизнеса, когда сталкивается с необходимостью смены системы учета (по причине перехода на новую конфигурацию 1С из-за устаревания текущей или перехода на 1С с другой учетной системы), встают перед выбором между двумя программными продуктами: 1С:ERP Управление предприятием 2.5 и 1С:Управление холдингом 3.2.

В статье рассмотрим, на что следует обращать внимание при принятии решения о выборе того или иного продукта.

Сегодня вышел подробный отчёт о состоянии DevOps в России. В исследовании этого года приняло участие рекордное количество респондентов — больше 4100 линейных специалистов и руководителей. В статье мы расскажем, что узнали про инфраструктуру российских компаний: какие ОС чаще используют на серверах, где хранят логи, какие системы контроля версий предпочитают и как меняется картина от года к году.

Несколько лет назад произошел Kafka-хайп. Kafka хотели использовать все, не всегда понимая, для чего конкретно она им нужна. И сегодня многие продолжают брать Kafka в свои проекты, зачастую ожидая, что её применение само по себе сделает всё лучше.

С одной стороны, это может быть и хорошо. Такие шаги стимулируют индустрию. Но всё же лучше понимать, что ты делаешь, иначе проекту можно сделать только хуже. В этой статье я обращаюсь к разработчикам, аналитикам и тестировщикам, которые еще не сталкивались с Kafka по работе. Помогу понять, почему все же в микросервисной среде многие не ходят просто по REST, а используют этот инструмент - что конкретно делает Kafka и когда есть смысл её применять.

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

Привет! Меня зовут Дмитрий. Я архитектор решений в крупной российской компании, более 15 лет проектирую, пишу код и руковожу командами. Сотрудничаю с Практикумом как ревьюер курса по Java и как автор курса «Архитектура программного обеспечения» в Яндекс Практикуме.

Предположим, вы решили развлечься дизайном систем (System design), пусть даже и не добровольно, на собеседовании. Если компания поленилась поделиться рабочим контекстом, то задача может быть в формате «запроектируй Твиттер». Более кандидатоориентированная компания N может попросить «спроектируй поиск на сервисе N».

Хотя статей типа «как запилить Твиттер» довольно много, не все помогут сориентироваться на реальном собеседовании. В этой статье предлагаю покопать вглубь и составить чек-лист, некий алгоритм. Он будет чуть шире, чем принято «для Твиттера», хотя универсальным его сделать не получится. Мне эта схема помогала и помогает, хотя у каждого свои фишки и предпочтения. 

Привет, с вами команда “Инферит Клаудмастер”. Сегодня мы хотим рассказать вам о нашем опыте практического применения Канбан-метода в разработке. Для этого мы пообщались с Лилей Ермаковой, Service Delivery Manager, которая своими руками лидировала внедрение нового процесса.  

Несколько дисклеймеров:  

Мы все еще продолжаем наш путь в Скрамбан и не претендуем на завершенный и идеальный результат. 

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

Канбан, как замечают коллеги, — очень перегруженное слово. Задам координаты теории, на которую я ориентируюсь, — это материалы Канбан Университета и ProKanban.org. 

Исходная ситуация 

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

Модули продукта завязаны на общие компоненты, при этом имеют собственную специфику и область применения: один модуль для аналитики, другой для автоматизации инфраструктуры.  

Из этого вытекало два следствия: взаимозависимость работ в командах и специализация команд на задачах с разной спецификой.  

Как был организован процесс? 

У каждой команды своя культура, правила, длина спринта и свой продакт. Посередине — человек, который все объединяет в одно — Technical Product Owner. Если вы скажете, agile солянка, то будете правы.  Релизы получалось делать раз в месяц (в лучшем случае). Помимо разработки, необходимо было объединить результат обеих команд и провести общее регрессионное тестирование.  

В мире победившего эджайла, SCRUM, как один из наиболее популярных фреймворков, казалось, имеет все шансы стать отраслевым стандартом. Однако в результате врождённых недостатков он стала чем-то средним между религией для занятых проектным управлением и воздухом для продажи эджайл-коучами. Более того, сегодня строгая приверженность принципам SCRUM нередко становится маркером профнепригодности для людей, которые имели неосторожность переродиться из полноценных проектных методологов и руководителей в фанатично зацикленных на ритуалах scrum-мастеров (речь не обо всех, но о об очень многих). В посте попытался обобщить все проблемы SCRUM, как "фреймворка" для проектного управления и создания продуктов.

Представьте ситуацию: вы приходите на новую работу, а вас встречают хмурые лица, никто не знает, куда вас посадить, а руководитель куда-то пропал. Знакомо? К сожалению, многие компании до сих пор недооценивают важность правильного онбординга сотрудников. Ниже гайд рассказывающий что нужно сделать, чтобы все было идеально, конечно, с примерами из жизни компании SEOWORK

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

Привет! Меня зовут Аня, я руковожу проектными менеджерами. Более 8 лет работаю в сфере people management и понимаю, как сходу отличить замотивированного сотрудника от выгоревшего. На любой позиции моей главной задачей было развивать сотрудников, а потом удерживать любым доступным способом. 

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

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

Если у вас есть время и желание заняться странной деятельностью, я предлагаю вам развлечение под названием «кадровая археология». Суть проста — вы вводите в поиск запрос, вроде «вакансии в России в 1990-х» и по ним пытаетесь понять, как жили древние люди. А точнее, как мыслили HR‑ы и их руководители, а также, какой была ситуация на рынке труда.

Наша задача на сегодня — проанализировать ряд найденных артефактов было эпохи, дойти до наших дней и понять, как развивалась корпоративная культура, зачем она нужна и предположить, куда же она приведет. А сделать это можно только через гадание на таро и кофейной гуще футурологические прогнозы социально‑экономической ситуации. Hi‑tech, low life и манипуляции — вот краткое содержание этой статьи.

В чем реальная причина вашего забитого календаря и как этого избежать

Недавно компания Shopify решила уничтожить все свои собрания, и почему‑то это стало новостью. Несколько лет назад Airbnb объявили «амнистию календарей» и все календари были в одночасье вычищены. Это были благие намерения, и это было прекрасно — в течение короткого срока.

Часто бывает, что в конце квартала подводят итоги и все классно поработали, все выполнили свои KPI, но при этом сам бизнес получил посредственный результат.

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

Вот вам типичная история: есть компания N численностью 2 тыс. сотрудников, люди работают на производственных площадках и в офисах. Вдруг усилилась текучка, и поток новичков ломает хоть как-то выстроенные процессы. Руководители жалуются, что сотрудники элементарно не понимают, как оформить нужные документы и получить технику, задают много вопросов (или не задают и ничего не понимают). Да и погружение в рабочие задачи  хорошо идёт только там, где за этот процесс взялся прямой руководитель (читай: бросил часть дел и отвечает на все вопросы). 

Кто виноват и что делать? Мой ответ такой: конечно, нужно прописать регламенты и создать нормальную систему интеграции новых сотрудников в компанию. Но быстрое решение — хотя бы собрать единую базу знаний с ответами на часто задаваемые вопросы и разместить её на корпоративном портале. 

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