Пользователь
Всем привет! Меня зовут Андрей Софронов и я тимлид продукта “ЭДО и S2P”.
Хочу поделиться с тобой своим опытом и наблюдениями о том, что важно в управлении проектами, как можно посмотреть на проект и свою деятельность в целом, что следует учесть, что помнить и о чем позаботиться. Моя статья будет полезна как тем, кто только начал свой путь в управлении проектами, так и опытным руководителям, т.к. всегда полезно разложить по полочкам то, что знаешь и умеешь.
Испытательный срок – сложное время. Нужно разобраться в проекте, процессах. Привыкнуть к новой компании. А если ты тимлид? Ко всему этому нужно еще и быстро разобраться с командой и показать какие-то результаты руководству. Сложность возрастает.
Что делать тимлиду, чтобы эффективно пройти испытательный срок? Приглашаю почитать.
Наверно, многие из моих читателей как раз закончили квартальный (и/или годовой) цикл планирования, так что сейчас будет подходящее время напомнить, что процесс, которым мы пользуемся как стандартом в технологической отрасли, на самом деле — полная чушь. Разумеется, я имею в виду методологию Objectives and Key Results. Давайте же поговорим об OKR, что это такое и откуда они взялись, а ещё о том, почему это ужасная идея.
Есть у нас такая традиция – начальство не любить. А как быть, если начальство – ты сам? Хочется ж быть хорошим, всегда и для всех. Но получается так, увы, редко.
Как понять, что про вас думают сотрудники, как повлиять на эти мысли, что нужно делать, чтобы помимо оценок “не бесит” иногда проскакивали и “отличный руководитель!” давайте разберемся в статье. Прошу под кат.
Минувший год хорошенько испытал на прочность многие IT-компании. Некоторые закрылись, некоторые релоцировались, некоторые локализовались на своих рынках. Это был настоящий челлендж.
Наша компания также проходила сложную трансформацию весь прошлый год. И одной из важнейших целей, которую мы перед собой ставили, было сохранение команды. Потому что в нашей сфере именно люди – основа любой компании.
Про нашу историю, выводы, а также некоторые инструменты, которые нам помогали, приглашаю почитать.
Коллеги, всем привет!
В наши дни, наверное, каждый хоть раз слышал слова «коучинг» или «коуч» (а те, кто работает в ИТ, может быть, слышали эти слова чаще, чем хотели бы:)). Но как ни странно, далеко не каждый знает, что на самом должно стоять за этими словами. Поэтому в сегодняшней статье хотелось бы раскрыть две темы:
1. Дать представление о том, что такое коучинг в классическом понимании этого термина.
2. Рассмотреть несколько простых коучинговых инструментов, которые любой может использовать в жизни и в работе без какой-либо специальной подготовки.
Меня зовут Марина Перескокова. Я проработала в Яндексе 10 лет, и из стажёра-разработчика выросла до руководителя службы разработки фронтенда. За это время получилось поработать над JS API Яндекс.Карт, поруководить фронтендом сервиса yandex.ru/maps и покодить движок для векторной карты на WebGL. По итогам моего тимлидства я написала книгу.
В какой-то момент я поняла, что у ребят все хорошо и без меня, и попросила новых задач. Так я стала совмещать роль руководителя службы разработки с ролью менеджера продукта и занялась развитием дизайна подложки Яндекс.Карт. Это был очень интересный опыт, и с точки зрения работы над продуктом, и с точки зрения коммуникаций — для воплощения в жизнь некоторых задач приходилось состыковывать до пяти разных команд в разных отделах.
Я в двух статьях расскажу про свой опыт перехода из тимлида разработки в продакт-менеджера. Пройдём по всем аспектам: какие преимущества есть у разработчика, с какими сложностями вы можете столкнуться, как их преодолеть, что плохого и хорошего случится в пути, и главное: как понять, что это ваше.
В мире огромное количество людей, которые стали руководителями, а потом перехотели ими быть — в чем дело?
Когда мы молодые и амбициозные, то готовы брать все, что дают и радуемся любому повышению: «Вау, челлендж! Сейчас всем докажу! Я хочу быть руководителем, хочу власти и успеха!». На самом деле, мы не всегда понимаем, куда нас несет течение, что нас ждет на следующей ступени, на которую мы шагаем.
Я сделала короткий опрос в сообществе менторов по этой проблеме. Оказалось, что 16 из 22 менторов сталкивались с запросом «Как мне вернуться в специалисты?».
Меня зовут, Марина Перескокова, я уже 15 лет в IT, 10 из них проработала в Яндексе. У меня и моих знакомых тоже случались подобные проблемы. Давайте разберем 8 самых распространенных причин, почему руководитель больше не хочет быть руководителем.
В первой части я рассказывала о том, почему перешла из техлида в продакт-менеджеры, чем мышление продакта отличается от образа мыслей разработчика. И какие у продакта с техническим бекграундом есть сильные стороны.
Сегодня, как и обещала, расскажу про сложности, с которыми я столкнулась за год работы продактом и которые совсем не предвидела, соглашаясь на новую роль.
Вступительное слово
Для удобства я буду писать различные английские слова, такие как “Agile”, “coach”, “Scrum” и т.д. русскими буквами. Аджайл, коуч, скрам и т.д. Кто легко оскорбляется наличием транслитерации в тексте — прошу меня понять и простить.
Аджайл сегодня, как мгла из одноимённого романа Кинга, распространяется по планете Земля, проникая во всё большее количество сфер человеческой деятельности и в умы непосредственных деятелей.
К нашему всеобщему счастью в Аджайле обитают не только чудовища. Одно из порождений Аджайла, о котором сегодня пойдёт речь — аджайл коуч.
А стоит об этом поговорить, потому как всё чаще можно встретить людей, всерьёз рассуждающих, что лучше канбан, или скрам; увидеть компании, ищущие аджайл коучей/скрам-мастеров (именно в таком виде), и наткнуться на литературу, рассказывающую, что в начале было слово, и это слово было “Аджайл”.
И это опасная тенденция.
Привет! Меня зовут Курдюмов Дмитрий, я являюсь сертифицированным Agile коучем и консультантом по трансформациям компаний, больше 7 лет помогаю компаниями на пути к гибкости через трансформацию их подходов к управлению продуктами и проектами.
Тема команд стала актуальна с приходом Agile подходов. Но на самом деле процесс начался гораздо раньше. В 1986 году в Журнале Harvard Business Review вышла статья "The New New Product Development Game", в которой было сказано:
Новый акцент на скорость и гибкость требует изменения подхода к управлению разработкой новых продуктов. Традиционный последовательный или «эстафетный» подход к разработке продуктов, примером которого служит система поэтапного планирования, может противоречить целям максимальной скорости и гибкости. Вместо этого целесообразнее использовать «регби»-подход, где команда пытается преодолеть расстояние как единое целое, передавая мяч туда и обратно — что лучше соответствует текущим конкурентным требованиям.
Споры вокруг Site Reliability Engineering и DevOps подходов, обусловлены различиями компаний, команд, сервисов, объемов разработки, практик, инфраструктуры и культурного кода. На рынке IT, есть путаница, это правильно, можно по-разному практиковать DevOps и SRE, и разные инженерные команды могут выполнять эти роли. Тем не менее, существуют основые сходства и различия в подходах. Сейчас DevOps в тренде и будет пользоваться спросом ближайшие годы, SRE набирает популярность медленнее но все же актуален.
Меня зовут Илья, я фронтенд-разработчик в Авито, и я долго искал эффективный способ развития своих скиллов. Под катом я подробно описал весь свой путь и рассказал, получилось у меня это или нет. Интересно будет всем: и тем, кто только ищет свой путь, и тем, кто уже всё знает. Заходите)
Привет, Хаброжители!
Рассказываем, как создали понятную систему оценки качества для команд разработки Авито. Мы отобрали самые релевантные метрики, протестировали их, а затем показали коллегам, как ими пользоваться. Звучит просто, но на самом деле это был долгий и кропотливый процесс. Что получилось в итоге, читайте в статье.
Habr, привет! Меня зовут Женя, и в настоящий момент я лидер направления Self-Service BI в крупном FMCG. Очень хочется начать делиться с вами своими знаниями и наработками, поэтому в рамках первой небольшой статьи решил рассказать вам максимально просто о том, а что же такое Self-Service BI. Поэтому давайте познакомимся с основными подходами к построению Business Intelligence и поймем, почему важен процесс Self-Service.
Сельские учителя спросили, как готовить детишек, чтоб по способностям и возможностям они не отличались от ровесников, живущих рядом с ведущими университетами с их богатыми библиотеками и высокой научной культурой. Так родились эти лекции. Они хороши для работающих на результат учителей небольших городков и деревень, любящих естествознание школьников от 14 лет (либо детей от 7 лет с учителем), и, несомненно, студентов младших курсов университетов.
После долгого полёта в глубины космоса вы с другом попадаете в плен к загадочным существам. Вам предложен выбор: остаться пленниками или победить их в игре и стать свободными. Решение принято, и вы оба садитесь за игровой стол вместе с одним из чужаков. Инопланетянин раздаёт мешочки с черными и белыми камнями. Каждый игрок, не показывая другим, достаёт из своего мешка камень задуманного цвета, а затем все трое кладут их на стол. Победителем становится тот, кто выберет камень иного цвета, чем у двух других. Черный против двух белых или наоборот. Выигравший получает монетку и кладёт на свою сторону стола. В конечном итоге победит тот, у кого окажется больше монет.
Помимо правил, в самом начале с вами поделились интересной информацией. Вероятность того, что инопланетянин достанет чёрный камень — всегда 50%. За несколько секунд до начала игры друг шепнул вам о стратегии, которой нужно придерживаться. И в результате, после бесконечного числа партий, вы оба стали победителями. Просто подфартило? Или сработала стратегия партнера?
Если вы занимаете руководящую должность, очень важно регулярно проводить индивидуальные встречи с сотрудниками из своей команды. “Зачем, если я и так вижу их каждый день, и мы обсуждаем все, что происходит?”. Эти встречи не только помогают понимать, как чувствуют себя коллеги, но и дают возможность откровенно дать и получить обратную связь без посторонних. А также предполагают, что оба участника будут готовиться к собранию, рефлексируя насчет прошедшего периода после предыдущей встречи.
Я Алексей Анисимов, в настоящий момент управляю юнитом разработки в hh.ru и уже 10 лет руковожу разными людьми и командами в области ИТ. За это время я провел большое количество встреч 1 на 1 с сотрудниками — попробовал различные варианты, сталкивался с трудностями и совершал ошибки. Все это в результате помогло мне выработать для себя определенные принципы проведения индивидуальных встреч, которыми я хочу поделиться в статье.
О простых и продвинутых способах запуска PostgreSQL в Docker: добавляем healthcheck, ставим на мониторинг, настраиваем параметры.