Можно сказать, что на данный момент самый распространенный подход в гибкой адаптивной разработке продуктов - Scrum. Одна из ролей в Scrum - собственно Scrum-мастер. Роль, в зоне ответственности которой лежит обучение команды, правильная настройка процессов в команде, выявление и устранение препятствий в работе.
Если руководство и команда не обладают опытом в работе по Scrum, можно ли понять вообще, чем на практике должен заниматься Scrum-мастер, эффективно ли он выполняет свою работу?
Казалось бы, с документацией всё просто — пишешь, публикуешь, поддерживаешь актуальность. Например, вот у нас в Ozon есть пользовательские инструкции на docs.ozon.ru: выглядит просто как текст на сайтике, что ж необычного-то в его размещении и в целом в работе техписателей?
Если начать раскапывать, всплывёт ещё несколько вопросов:
• где хранить тексты и почему Confluence не подходит?
• как красиво оформить документацию с помощью статических генераторов сайтов
• зачем техписателям знать git и CI/CD?
• в какой момент пора искать разработчиков в команду и превращать документацию в платформу?
На связи Катя — руководитель отдела технических писателей в Ozon, и сегодня расскажу о платформе Docs Ozon изнутри.
Ух уж эта «приоритизация задач»! Если в Google или на том же Хабре поискать это словосочетание, вылезет огромное ĸоличество ĸлассных статей, в том числе и академических, с информацией о фреймворĸах, их плюсах и минусах. Вот примеры этих статей, чтобы вы не исĸали:
Приоритизация в Scrum по ICE. Опыт Авито
Почему приоритизация по трудозатратам и ценности не работает
Сегодня уже я буду рассĸазывать о своем опыте работы с приоритезацией задач. Мой опыт продуĸтовой разработĸи начался оĸоло восьми лет назад в одной броĸерсĸой ĸомпании. На тот момент еще не были популярны «продаĸт-менеджеры», я скорее работал бизнес-ĸонсультантом — делился с ĸомандой разработĸи болями ĸлиентов, указывал как можно улучшить сервис, чтобы заработать и не потерять денег.
Всем привет, я Алексей Некрасов @letitshine (@znbiz) — Lead направления Python в МТС и старший архитектор в MTS AI. Вместе с коллегой Галиной Прохоровой (@letitshine — product manager в MTS AI — решили поделиться историей внедрения методологии Event Modeling в существующий продукт. Мы расскажем, с какими трудностями наша команда столкнулась и как их преодолела.
Привет, Хабр! Меня зовут Герман Холмов, недавно я публиковал статью, посвященную нюансам проведения крупных мероприятий по информационной безопасности. Ну а сегодня расскажу о еще одном проекте Positive Technologies, который я помогал реализовывать. Речь идет о маркетинговой платформе, которую мы с командой создали для запуска продуктов компании - прежде всего, в онлайне. Забегая наперед - все получилось. Если вашей компании нужно анонсировать/продвигать запуски новых продуктов, то статья может оказаться интересной. Как водится, все подробности - под катом.
Привет, Хабр! Ранее я писала о том, как адаптировать тестировщика, который только-только приступил к работе на проекте. В этой статье я хочу уделить особое внимание адаптации нового сотрудника на проекте и почему это так важно: проведу сравнительный анализ одного и того же проекта на основе своего опыта и кураторства нового тестера.
Недавно прочитал шикарную книгу «Deadline», за авторством Тома Демарко, главы международной консалтинговой компании Atlantic Systems Guild, специализирующейся на построении сложных бизнес-систем, управлении рисками, реинжиниринге, построении здоровой корпоративной культуры.
«Дедлайн» – это роман об управлении проектами, его автор в художественной форме преподносит реальные практики набора сотрудников в команду, распределения команд, делегирования и организации различных процессов.
Продолжение рассказа про разработку pet-проекта о кафе и коворкингах на солнечном Кипре. "Рабочие места" для цифровых кочевников ヽ(。_°)ノ
В первой части я рассказал про REST API микросервис, теперь - про фронтэнд-сайт.
Бывает, что обязанности в команде вроде бы чётко закреплены, но что-то не ладится. Сотрудники не попадают в ожидания друг друга и путаются, кто кому ставит задачи, а кто утверждает результат. Verno, центр экспертизы red_mad_robot, рассказывает о распределении ответственности.
Здравствуйте. Меня зовут Евгений Пригаров, я руководитель программы проектов в ГК Юзтех. С 2006 года я занимаюсь оценкой проектов, работал на пресейлах в 4-х компаниях разного масштаба. В совокупности за эти годы я отработал 1000+ пресейлов.
В этой статье я хочу поделиться своим личным опытом, подходом и рекомендациями к оценке проектов и созданию технико-коммерческих предложений (ТКП). Эти рекомендации довольно простые и, возможно, покажутся банальными, но на мой взгляд, они хорошо работают. Они позволяют разумно и эффективно использовать время и возможности.
Из статьи вы узнаете:
1) Как качественно оценить проект?
2) Как создать качественное ТКП?
3) Как качественно подать результаты оценки?
Дисклеймер:
— Качественная оценка и ТКП не гарантируют победы в пресейле;
— Качественная оценка и ТКП не гарантируют успешного выполнения проекта. Чтобы проект был выполнен успешно, нужно и на всех последующих этапах проекта отрабатывать возникающие задачи на пределе своих возможностей.
Про работу на нескольких проектах
Многозадачность в тренде, но еще не у нас
Кто может?
А эффективно?
Сколько брать?
Принципы и рекомендации
По личному опыту удаленки в малом бизнесе
У вас была ситуация, когда не получалось завершить какое-нибудь дело? Это мог быть рабочий проект, ремонт в спальне или желание сбросить ненавистные лишние килограммы? Если да, то замечали ли вы, что если мы начинаем (или хотим начать) дело, но не доводим его до финала, последствия сказываются не только на нас, но иногда и на окружающих?
Привет! Меня зовут Хусен Гапурхаев, я скрам-мастер в Beeline Казахстан, и в работе часто сталкиваюсь с необходимостью делать одновременно большое количество задач (причем как своих, так и в работе наших продуктовых команд).
В этой статье поделюсь, как помогаю себе справляться с незавершенными делами. Возможно, что-то из этого будет полезно и вам.
Процессы слияний и поглощений компаний различных отраслей постоянно происходят на рынке. Изменение структуры компании, безусловно, затрагивает ИТ-процессы и специалистов. В этой статье я предлагаю поделиться фрагментом нашего собственного опыта, на что важно обратить внимание в части ИТ, когда предстоит решать вопрос о приобретении бизнеса.
В основе нашего подхода – интересы бизнес-заказчика и возможные дополнительные ИТ расходы. На практике уже выработался следующий чек-лист, и он не зависит от рода деятельности рассматриваемой компании:
Корпорация Microsoft еще весной 2022 года объявила о приостановке бизнеса в России. Соответственно, пользователи из РФ не могут покупать лицензии на программное обеспечение компании, включая продукты для управления проектами и портфелями проектов MS Project Server. Наверное, у некоторых компаний из России еще работают облачные версии платформы, но только до момента завершения срока действия подписки.
В общем, приходится искать альтернативы среди отечественных продуктов (ну, чтобы уж точно все работало без внезапного отзыва лицензий и прочих проблем). Недавно я как раз занимался таким поиском и нашел несколько альтернативных MS Project Server систем, которые и предлагаю обсудить в этом посте.
История об ошибках и решениях, которые позволили пережить пандемию, локдауны, протесты и заработать за четыре года более $3 млн.
Я не очень понимаю, почему об этом мало кто рассказывает.
Есть две на редкость противоположные сущности: банковские требования к производству кода и желание как-то гибко разрабатывать. В итоге получилось два страшных типа команд: те, кто работал по плану и стабильно делал релиз раз в полгода, и те, кто работал по аджайлу и не делал релиз раз в неделю.
Почему модные и молодёжные аджайл-команды релиз не делали? Потому что у них было готово всё кроме одной мелочи — например, разработанных и согласованных архитектурных документов на решение с инетрпрайз архитектором и безопасником. То есть процесс, который можно условно назвать «ГОСТ», приходил к ним в лице суровых грустных мужиков. И заставлял их проходить все этапы согласований, начиная с оценки возможного риска и заканчивая какими-то «совершенно ненужными» тестами, согласованиями требований с юристами и прочей хтонью, которая нормальному человеку покажется адом. Но именно по этому аду нужно было пройти, сделать с десятка два документов, согласовать каждый и только после этого выходить в продакшен. Где-то месяца через два.
Думаю, вы и сами представляете, как оно происходит в банках. Именно поэтому многие разработчики <sarcasm>так стремятся</sarcasm> в них работать.
Когда я прикоснулся в Газпромбанке к организации производства, то как раз застал несколько «ГОСТ-команд» с совершенно безнадёжным TTM и много аджайл-команд, бьющихся в истерике от требований.
Привет! Меня зовут Валерий, я руковожу группой QA Fullstack компании SimbirSoft. В сфере тестирования чаще всего выделяют группы QA-специалистов и SDET. Но сейчас многие компании задумываются об оптимизации расходов, особенно это актуально для проектов с длительным периодом эксплуатации, вроде небольших монолитов или внушительных размеров систем с множеством интеграций и микросервисов. Рано или поздно наступает момент, когда требуется подключать специалистов, которые не только хорошо разбираются в продукте и могут тщательно его протестировать, но и тех, кто могут писать автотесты. Убить двух зайцев сразу помогут QA фулстеки.
В этой статье расскажу о том, как QA фулстеки могут существенно улучшить тестирование ПО, на каких проектах они принесут пользу, а для каких задач и почему лучше обратиться к другим специалистам. Материал будет полезен всем, кто хочет обеспечивать качество ПО на высоком уровне и увеличивать скорость выпуска новых релизов, оптимизируя при этом расходы на найм дополнительных специалистов.
