Запуская свои первые эксперименты, я считала, что все эти «три / пять / семь самых популярных ляпов», о которых читала в статьях и слушала на конференциях — уж точно не про меня. Тем более в дизайне теста помогал большой красивый шаблон исследований, принятый в компании.
Но на практике ждали подводные камни. Давайте поговорим, что может случиться, если вы немного налажаете в дизайне или недоработаете заполнение своего шаблона. И как все это исправлять.
Читать полностью »
Сегодня, в 20:00 во всех наших соцсетях пройдет прямой эфир с Алексеем Левановым, исполнительным директором в Сбербанке.
Леша пришел в Сбербанк в 2014 году на позицию Junior-разработчика. Сейчас он исполнительный директор: Product Owner и Teamlead платформенной команды Sberbank Investor и занимается МП Сбербанк Инвестор и Школами Разработки Сбербанка.
Леша расскажет на примере своего пути: как расти и развиваться в крупной компании, каких ошибок стоит избегать и как инициировать изменения. Поговорим про вызовы и возможности, про work-life balance, про то, как не выгореть и вернуться, если все же выгорел.
Стрим можно будет посмотреть в любых наших соцсетях — где удобно, там и смотрите.
21 августа мы поговорили в прямом эфире с Павлом Жовнером. В прошлом месяце zhovner со своей командой запустил на кикстартере тамагочи для хакеров Flipper Zero.
Целью было $60 000, но меньше, чем за сутки, флиппер собрал миллион долларов, а к финалу собранные деньги приблизились к отметке $5 млн.
Как и многиее, я наблюдала за проектом уже почти год. Больше всего меня восхищало, как Паша набрал сильную команду под проект без финансирования и твердой рукой вел ее к готовому продукту и окупаемости: именно об этом мы и поговорили. А также о том, куда пойдут деньги, как мотивировать самого себя и как именно собралась команда флиппера.
Читать полностью »
Я работал в команде, которая делала десктопное приложение для VPN. Не самая простая штука в мире, много нюансов, много обратной совместимости. У нас были четыре разраба, три тестера, продукт оунер, проджект менеджер, сторонняя команда дизайнеров. Все по-серьезному. Помимо десктопного клиента делалась ещё и либа, которая содержала в себе всю бизнес-логику, и использовалась на других платформах. И эта либа в свою очередь использовала сишный бинарь, который и поднимал VPN туннель.
Если бы меня кто-то спросил, за сколько можно сделать такое приложение в одиночку — я бы сказал: «два месяца на разработку, один на тестирование». Но нас было много, поэтому мы работали больше двух лет.
Читать полностью »
Завтра, в 20:00 в наших соцсетях пройдет прямой эфир с любимцем публики Пашей Жовнером zhovner, создателем Flipper Zero, гиком и богомолом.
Стрим можно будет посмотреть в любых наших соцсетях — где удобно, там и смотрите.
Мы пробуем новый формат, нечто среднее между Ted Talks, стендапом и подкастом. В эту пятницу будем обсуждать с Пашей:
Меня зовут Ростислав Салата, я работаю в киберспортивной организации без малого три года. Пришел в компанию на должность проектировщика интерфейсов, дорос до UX-лида, и в настоящее время являюсь продуктовым менеджером.
Задачи продуктового менеджера и подход к работе у нас сильно отличаются от обязанностей продуктовых менеджеров в других компаниях. Это значит, что в вашей компании представления о функционалах и наборе скилов для продуктового менеджера и дизайнера могут отличаться. Например, в некоторых компаниях продуктовый менеджер проектирует интерфейсы, а у нас – нет.
Почему я поднял эту тему? Мы провели очень много собеседований с продуктовыми дизайнерами. Опираясь на свой опыт и опыт коллег, могу смело сказать, что вопрос о круге обязанностей задает каждый претендент. Разное понимание зон ответственности может впоследствии привести к конфликтам, которые пагубно повлияют на продукт.
Ниже не будет чек-листов и стопроцентной инструкции о том, как перейти в менеджмент. В первой части статьи я развею мифы о «кажется, я уже продакт». Во второй части расскажу о реальных задачах менеджера по продукту. Точнее о тех, с которыми я сталкиваюсь ежедневно и которые должны развеять идеалистическое представление о том, что такое продуктовый менеджмент.Читать полностью »
За годы работы архитектором я видел разных заказчиков, и одна из самых частых ошибок формулирования ТЗ и хотелок заказчика — это смешение разных уровней абстракции. Приходит человек и говорит:
— Мне нужна железка, которая будет управлять приводом дверей, и показывать на семисегментном экране текущее состояние, и обязательно с внешним сервером для удаленного управления, чтобы по TCP общалось с этим сервером, а для панели управления взять VueJS.
Вроде, понятно, что человек хочет. У кого-то даже такое ТЗ вызывает энтузиазм — человек, казалось бы, четко понимает, чего хочет. Зачастую он даже указывает на конкретные контроллеры/компоненты/фреймверки/протоколы.
И по такому заказу, безусловно, можно сделать нужную железку. И она даже будет работать, если подобранные компоненты не противоречат друг другу. Но если расчет идет не на проект, а на продукт, и его потом необходимо будет поддерживать, то гораздо полезнее потратить время и аккуратно разделить эти хотелки по уровням, понять, зачем именно такой экран, почему TCP, и причем тут VueJS. Вполне может оказаться, что это технологии, к которым заказчик испытывает приятные чувства из-за синдрома утенка. Или он просто не знает, что есть и другие типы экранов.
Читать полностью »
В далекой-далекой галактике трудится сферический product owner. Он бегло пишет заметки на салфетке и молча отдает ее разработчикам. А вскоре получает готовый продукт, который на 100% соответствует его ожиданиям. Даже если продукт этот – сложный кроссплатформенный сервис с блэкджеком и адаптивностью.
Возможно ли такое на практике?
Читать полностью »
Относительно недавно вышёл фреймворк Digital Practitioner Body of Knowledge. Эта работа освещает крайне актуальную тему — запуск цифрового продукта и бизнеса. Моя статья — краткий обзор этого материала. В нём упоминаются популярные техники, которые применяются в различных аспектах деятельности цифрового предприятия.
По DPMBoK я готовил внутренний методологический материал. По-моему, этой весной всем стало понятно, что сегодня почти не осталось бизнеса, которому не требуется осуществить цифровую трансформацию, а данный пост может ввести в курс дела всех интересующихся этой темой или открыть интересную дискуссию в комментариях.
Недавно наше внимание привлёк один вопрос, заданный на stackexchange.com. Этот вопрос был направлен на то, чтобы разобраться с влиянием скрама на работу программистов. Автор вопроса, пользователь Qiulang, поднимает довольно смелую тему: «Скрам превращает хороших разработчиков в программистов средней руки. Возможно ли это?».
Основная идея фреймворка скрам заключается в организации процесса разработки для более быстрого выполнения работ на различных этапах жизненного цикла проекта. Но всегда ли такой подход подталкивает разработчиков к правильным моделям поведения? Многие пользователи, присоединившиеся к обсуждению вышеупомянутого вопроса на Stack Overflow, сталкивались с похожими вещами, когда разработчики «срезают углы», слишком большое значение придают высоким баллам, назначенным их тикетам, или даже прикидываются перед менеджерами высокопроизводительными сотрудниками. Как избежать этих опасностей?
Вопрос, о котором идёт речь, перешёл с workplace.stackexchange.com на softwareengineering.stackexchange.com. Это говорит о том, что программисты рассматривают соображения, связанные со скрамом и с его эффективностью, как нечто достаточно серьёзное, выходящее за рамки управления циклом разработки ПО. Они ощущают воздействие этого метода управления проектами на рабочую обстановку в целом.
Читать полностью »
