Итак, мы поговорили о том, зачем вам нужны требования, что они должны содержать и кто должен их писать. Это четвертая и последняя часть цикла статей про требования, в которой я хочу поделиться своим собственным опытом написания хороших требований.
Теперь когда вы прочитали все о том зачем нужно писать требования и из чего они должны состоять, давайте поговорим о том, кто должен их писать.
(Уже прочитали первую часть? Она находится здесь.)
Это серия статей о функциональных, а не о технических требованиях (и не о технических заданиях). Люди очень часто путают эти термины. Я не знаю есть ли какая-то стандартная терминология, но вот что я имею ввиду, когда использую эти термины.
Начиная работать руководителем команды программистов 7 лет назад, я наткнулся (или кто-то посоветовал, уже не помню) на блог Джоэла Спольски. Джоэл пишет с юмором и не понаслышке знаком с проблемами, с которыми сталкиваются компании разрабатывающие программы и сервисы. Прошли годы, но его статьи про требования до сих пор актуальны и я рекомендую познакомится с ними всем менеджерам проектов и продуктов, которые только вступают на этот путь.
Для тех, кто хочет познакомится с оригиналом — Painless Functional Specifications — Part 1: Why Bother? Я, как всегда, открыт к любым замечаниям по моему переводу!
Это достаточно свободный перевод статьи Ellen Chisa — The Dark Side of PM. Так как я и сам работаю в роли PM, я стараюсь делать более живой перевод таких статей, руководствуясь собственным опытом. Но если у вас есть какие-то замечания и\или предложения — то я всегда открыт для обратной связи в личных сообщениях или комментариях.
Не так давно я успешно закончил курс в Нетологии по управлению продуктом. Это был мой далеко не первый опыт обучения онлайн, но первый опыт обучения в Нетологии. На протяжении курса, и после его завершения уже с десяток человек попросили рассказать о курсе и\или об обучении в Нетологии, поэтому я и решил написать этот пост.
В начале я хотел подробно описать свое мнение и свое отношение к курсу, но потом решил, что просто подробнее расскажу про то, что курс представляет из себя внутри и про процесс обучения в Нетологии в целом, а там пусть каждый делает вывод на сколько ему это интересно.
В конце все-таки будет маленький кусочек моего мнения, для тех, кому оно интересно.
Читать дальше
Этот пост задумывался как перевод статьи. Но то, что в итоге получилось, сложно назвать переводом, это скорее пересказ. Причина в том, что язык оригинальной статьи сложен для восприятия и перевода. Множество предложений – ложные языковые конструкции. Автор также использует игру слов. Наверное, профессиональный переводчик способен создать перевод такого текста с минимальными изменениями. Но я к таким точно не отношусь. Поэтому я решил сконцентрироваться на смысле и разбить предложения на более простые, немного дополнив их от себя. Надеюсь, так текст станет более понятным для любого читателя.
Оригинальный текст действительно не содержит ни одной картинки и весьма объемный. Но я рекомендую его всем – он очень интересный.
Есть еще одна особенность – сама роль менеджера продукта. В Microsoft она называется менеджер программы. У этой роли в Microsoft немало специфики. Одной из причин, на мой взгляд, является специфика их продуктов. Вторая в собственном изобретении роли. Но в целом роль менеджера программы очень похожа на то, что в современном мире понимают под менеджером продукта.
Сразу замечу, что процесс разработки продукта в Microsoft не является очень гибким и скорее напоминает классическое управление проекторами по PMBok. Так что если вы адепт Agile, то наберитесь терпения :)
Одни из самых знаменитых людей в мире технологий — инженеры и дизайнеры. Они создали удивительные продукты, которые мы так любим — Instagram, Gmail, Twitter, Android, iOS, и другое ПО, “железо” и сервисы. Но не магия помогает им реализовать идею от начала и до конца — это тяжелая ответственность лежит на плечах менеджеров продукта (PM). Эти квалифицированные специалисты, возможно являются забытыми героями индустрии. Это люди, которые управляют каждым движением продукта на его жизненном цикле, принимают идею от CEO и исполнительного руководства и проводят её через разработку. Именно они помогают диктовать стратегию продукта и гарантировать, что он подходит пользователям компании.
На этой неделе, у нас был шанс поучаствовать в событии, которое собрало вместе сотни менеджеров продукта в сфере технологий под эгидой создания сети знакомств для обмена информацией и профессионального роста. Оно было организовано Ken Norton из Google Ventures и Josh Elman из Greylock Partners — двумя индивидуалистами, которые хорошо известными в сфере управления продуктом.
До начала события мы встретились с Нортоном и Элманом, чтобы больше поговорить о том, каково это быть менеджером продукта, о вызовах и о том, куда всё движется. Нортон рассказал нам, что управление продуктом по-разному определялось разными людьми, но всё больше людей начинает понимать, что управление продуктом может стать настоящей карьерой, а не просто чем-то, во что вы “погрузились”. Это именно то, что произошло с ним, когда он помогал создавать продукты в JotSpot и в Google, включая Google+, Mobile Maps, Calendar, и Docs.
Он приводит в пример большое число компаний и фирм, которые пытаться укрепить ряды своих менеджеров продукта. В частности, венчурная фирма Kleiner Perkins Caufield & Byers начинает программу стипендий сфокусированную на продукте начинает программу стипендий ориентированной на продукт, а CEO Yahoo Марисса Майер была инициатором Google’s Associate Product Manager program.
