Менеджер проектов
Команда ЮMoney проведёт митап про системную аналитику — уютный, но хардовый.
Темы докладов:
• Репозиторий архитектуры: 20 лет развития системы
• Documentation As Code, или «Легкий способ бросить вести документацию на wiki»
• Про сломанные грабли и разбитые лбы: проектирование в финтехе
Ждём вас 25 октября в 18:00 (мск).
Регистрируйтесь и зовите друзей: https://events.yoomoney.ru/analytics-code-2022.
План развития бывает навороченным, но сделанным просто для галочки. А бывает простым и наглядным, и работать с ним лучше, чем без. Разберёмся, как собрать удобный инструмент и на чём споткнуться, расписывая задачи себе и своим подопечным, если вы ментор.
Привет! Меня зовут Коля, я создатель одного из крупнейших каналов про релокацию и работу за границей Remocate. В этой подборке постарался собрать все ссылки, которые могут пригодиться в ближайшие дни.
Всем привет!
Делимся полезными материалами с недавно прошедшего митапа Frontend Mix, где экперты ЮMoney и Альфа Банка рассказали, как они создают продукт.
Американский маркетолог Бен Хант в 2010 году представил публике книгу «Конверсия сайта. Превращаем посетителей в покупателей». В ней он описал теорию, которая впоследствии получила название «Лестница узнавания Бена Ханта».
Автор книги предложил делить потенциальных клиентов по степени их осведомлённости о продукте. Согласно его теории, от полной неосведомлённости о продукте до покупки человек проходит 6 этапов (от 0-й до 5-й ступени). На каждом этапе у человека разные потребности, значит, и предложение стоит делать разным.
Если объединить его теорию с классической воронкой продаж, то получим лестницу, состоящую из 5 ступеней-этапов готовности клиента к покупке.
Привет! Я Дима, мне 28. Семь лет назад я устроился в техподдержку в Нижнем Новгороде. Расскажу, почему из менеджеров я перешел в технари и как стал продактом в Петербурге.
Работая над обзором и обновлением книги «Мифический человеко-месяц», я поразился, как мало тезисы, заявленные в ней, были подвергнуты критике, доказаны или опровергнуты текущими исследованиями и опытом в инженерии ПО. Теперь для меня оказалось полезным каталогизировать эти тезисы в сырой форме, лишённой подтверждающих аргументов и данных. В надежде, что эти голые утверждения привлекут аргументы и факты для доказательства, опровержения, обновления или уточнения, я включил этот план в главу 18.
В апреле мы провели ежегодный митап Пиэмная, где делимся кейсами и полезными советами для менеджеров проектов. Смотрите свежие доклады, из которых узнаете:
— Как на проекте создать команду мечты, не дожидаясь суперзвезд.
— Как выстроить отношения с бизнесом, когда сделать абсолютно всё невозможно.
— Что делать, если ваш основной пользовательский продукт — это API.
— Как не надо управлять масштабными проектами: вредные советы для PM.
Где-то в мире живёт Серёжа — тридцатилетний продавец обуви и отец троих детей.
Представим, что Серёже в какой-то момент надоело продавать одинаковые туфли и захотелось делать одинаковые лендинги. Он почитал статьи в интернете, посмотрел 70-часовые разборы разборов по вёрстке на Ютубе, прошёл курсы. Даже купил «Алгоритмы» Скиены, но пока не открывал. В общем, любым способом научился программировать.
Как ему теперь поступить, чтобы мечта «максимально хорошо начать карьеру» стала реальностью (если это вообще выполнимо)? Как и в любой профессии, есть несколько вариантов. Сколько из них хороших — непонятно, будем разбираться.
Дисклеймер: осторожно, этот пост может задеть чувства Java и 1С-разработчиков, менеджеров проектов и владельцев парикмахерских.
Привет всем, меня зовут Илья. В ИТ я работаю около 6 лет, последние 2 года — в компании «Яндекс.Деньги» фронтенд-разработчиком. В обязанности входит поддерживать/развивать части приложений, в данный момент проект «Личный кабинет» (и нет, это не просто «в ие неправильные отступы поправить», «кнопке цвет поменять» или «быстро форму сошлепать»).
В отделе разработки у нас есть внутренний проект Challenges — так мы называем задачи, не связанные напрямую с основными продуктами. Это задачки, которые будут общественно полезны, помогут улучшить инфраструктуру, CI/CD и другое. Например, доработать бота, оповещающего о релизах, сделать плагин для IDEA по автогенерации assert по объекту и провести рефакторинг старой UI-библиотеки. Такие «вызовы» можно брать по желанию — они прекрасно подходят для разбавления бизнес-задач.
В один прекрасный момент я взял давно интересующую меня задачку по реализации автоматической проверки размера клиентского бандла приложения. Ведь всё, что можно проверять автоматически, лучше проверять автоматически.
Естественно, итогом стала не просто конкретная реализованная задача, а библиотека с правилами и общими функциями (ядро/core) для реализации любых чекеров (я надеюсь). В процессе решения задачки были набиты шишки, о которых тоже хочется рассказать.
Итак, есть Jenkins, Bitbucket, почта (или Telegram, Slack — что понадобится) и необходимость проверять размер бандла. Надо это всё подружить.
От переводчика: данная статья является переработкой английской статьи по паттернам разработки. В процессе адаптации на русский немало пришлось изменить. Оригинал
Выбор между различными паттернами разработки, всегда сопровождается рядом споров и дискуссий, а разные взгляды разработчиков на это еще больше усложняют задачу. Существует ли решение этой идеологической проблемы? Давайте поговорим о MVC, MVP, MVVM и MVI прагматично. Давайте ответим на вопросы: “Почему?”, “Как найти консенсус?”
Привет, это Наташа, лид-редактор в UX Яндекс.Денег. Я пишу этот текст, потому что больше не могу молчать о своей работе.
Раньше про нас думали, что мы копирайтеры. Пишем получше, чем менеджеры. Умеем проверять грамотность. Редактируем, чтобы стало понятнее. Убираем лишние слова.
Теперь думают, что мы писатели микротекста. Изобретаем правильный коллтуэкшн для кнопки. Проверяем, правильно ли называется ссылка. Режем всё, что плохо лежит.
При разработке продукта редко обращают должное внимание на его производительность при высокой интенсивности входящих запросов. Этим занимаются мало или не занимаются вообще – не хватает времени, специалистов или оправдываются типичной фразой: «У нас на проде и так всё быстро работает, зачем ещё что-то проверять?». В таких случаях может наступить момент, когда прекрасно работающий продакшн внезапно падает из-за нахлынувшего потока посетителей, например, под Хабраэффектом. Тогда становится ясно, что заниматься исследованиями производительности действительно необходимо.
Эта задача многих ставит в тупик, поскольку есть потребность, но нет ясного понимания, что и как надо измерять и как интерпретировать результат, порой даже нет сформированных нефункциональных требований. Далее я расскажу о том, с чего стоит начать, если вы решили пойти по этому пути, и объясню, какие метрики важны при исследовании производительности, и как ими пользоваться.
Иногда молодые команды разработки охватывает неразбериха.
Это случается в тот момент, когда они ещё не до конца разобрались, что такое эджайл; проджект и продакт спорят, кто из них кто, а задачи каждый ведёт сам по себе. Или все уже всё знают, но планировать спринты не получается — задачи не прорабатываются, демо и ретро проходят нерегулярно.
У нас тоже была похожая история, но мы нашли свой путь.
Это рассказ от команды личного кабинета Яндекс.Кассы, и подробнейшая инструкция для тех, кто хочет улучшить своё планирование.
