Чуйте аудио версията на тази статия

Неправилната комуникация между екипите за разработване на продукти и технологиите е може би най-големият източник на загуба на ресурси при разработването на софтуер. Технологичните компании с висок растеж се сблъскват с нарастващи изисквания за продуктите и по този начин правилното планиране понякога се пропуска. Има множество признаци, които показват липса на подреждане на продуктовия и технически екип:

• Продукти, които не са доставени според изискванията.
• Доставянето на продуктовите характеристики отнема повече време от планираното.
• Екипите имат много малко взаимодействие и комуникация на седмична база.
• Техническият екип трябва да „преработи“ своята инфраструктура поради нови заявки за продукти.
• Темпът на развитие се чувства бавен в сравнение с конкуренцията.
• Техническият екип често пита: „ Защо не ни каза това преди? '

Успешните компании активно управляват този интерфейс между двата екипа и имат ясни пътни карти за продукти и технологии, които са разбираеми от всички. Понастоящем обаче няма популярни методологии, които решават този проблем по структуриран начин.

Вместо това през повечето време тези цели се постигат по ad hoc начин чрез неструктурирани срещи. Най-близкото сравнение с това е мащабирани Agile рамки , но дори тези подходи не винаги са осъществими за всички компании, особено за по-малките, тъй като този подход изисква приемането на цялата рамка.

Един от начините за лесно постигане на съгласуваност между екипите за продукти и технологии е използването на структурираното платно за технологични продукти

Какво е платното на технологичния продукт?

Концепцията на платното съществува от много години. Ключовите визионери и новатори в това пространство включват Александър Остервалдер, който е създал Платно за бизнес модел , Роман Пихлер и неговите Product Vision Canvas и Джеф Патън, който е известен с Картографиране на потребителска история метод и неговия Възможност Платно . Използвах методологията на платното за решаване на проблема с подравняването на продуктите и технологиите и създадох Technology Product Canvas.

Платното ще действа като бърз начин да улесни обсъждането на екипа и да насочи всички на една и съща страница - буквално. Това е едно от най-важните предимства при създаването на този документ. Преминавайки през процеса, който може да отнеме по-малко от час, ще започнете да управлявате това привеждане в съответствие между продуктовите и технологичните екипи.

кристал (език за програмиране)

Платформата за технологични продукти принуждава вашия екип да формулира и визуализира целите на пътната карта на продукта, целите на пътната карта на технологиите и да обсъди изрично всеки етап от технологията на продукта. Това упражнение гарантира, че екипите са синхронизирани и всеки може да излезе от стаята с ясни очаквания и насоки.

Чрез работата си с технологични компании забелязах, че пресечната точка между бизнес целите и технологичните възможности е там, където се крие най-големият риск. Платформата за технологични продукти е създадена, за да управлява точно този риск.

Кога да използвам платното на технологичния продукт?

Дискусията за технологичния продукт Canvas е най-добре инициирана от собственик на продукта когато сте дефинирали напълно визията на продукта, провели сте процеса на картографиране на историята и разработили първоначалната пътна карта за пускане на продукта. На този етап ще стане ясно кои характеристики на продукта са критични за всяко основно издание. На този етап екипите са готови да проведат подробна техническа дискусия за как продуктът ще бъде изграден.

Упражнението Technology Product Canvas ще внесе яснота, понякога конфликт, но в крайна сметка ще постигне съгласие относно това каква технологична архитектура ще трябва да бъде въведена за разработване на продукта и как технологичните платформи ще се развиват, за да отговорят на нуждите на продукта. Това ще позволи на технологичния екип да размишлява върху различни възможности и да гарантира, че техният принос за иновациите ще бъде уловен.

Нека да разгледаме по-подробен пример за това как Technology Product Canvas се използва в хипотетично ново софтуерно начинание, за да можем да го видим в действие и да научим как да го използваме.

как да създадете rest api

Как да използвам платното на технологичния продукт

Платното Technology Product трябва да бъде преди всичко средство за създаване на фокус, комуникация и подреждане на екипа. Платното ви позволява да проведете разговор с вашия технологичен екип, за да разберете каква технологична архитектура ще е необходима за подкрепа на разработването на продукта. Нека използваме хипотетичен пример за нов софтуерен продукт. Ново приложение, базирано на местоположение, за да свързвате хората с другите около тях - приложение за общност, което да ви свързва със съседите ви.

Можете да изтеглите платформата за технологични продукти тук . Можете също така да разпечатате платното и да пишете върху него. Като алтернатива можете да използвате и онлайн инструмент като гледам , който използвах за тази статия.

Настройвам

Да приемем, че работите със своя стартиращ екип от няколко месеца, имате няколко чудесни идеи и сега искате да планирате разработката на софтуера. Работили сте върху постното си платно, дори сте създали история на стъпките на процеса, които потребителят ще изпита, докато премине през приложението. Сега трябва да го изградите. И така, качвате всички в конферентна зала, вашия продуктов екип и технологичните ви екипи и проектирате празна версия на Technology Product Canvas на екрана на конферентната зала. Къде да започна?

Първото нещо е да зададете очаквания защо всички са тук и какво се стремите да постигнете. Обяснете на вашия екип, че те са тук, за да осигурят план между целите на продукта и техническите задачи. Също така подчертайте, че не търсите съвършенство и че ще продължите да преглеждате това на всеки няколко месеца, докато научавате повече и изискванията се променят. Но поне за днес това е залог в земята, за да сте сигурни, че всички сте на една и съща страница.

Стъпка 1: Определете показателите за успех

Как ще измервате дали вашият цялостен план работи? Какви са бизнес целите? Те може да са приходи във всяка фаза на пускане или брой изтегляния на приложения. Ако сте запознати с постното платно, може би вече сте идентифицирали такива номера. Копирайте тази информация в този раздел. В този пример използвах следните две показатели за успех: „Свържете 1000 души през първата ни година“ и „Създайте нашата марка в Лос Анджелис“ - една количествено измерима и една качествена метрика.

е обратно съвместим с php 7

Но защо първо се фокусираме върху това? Той гарантира, че целият екип разбира защо сме в стаята. Имаме цел да постигнем, която е по-голяма от всеки продукт или технологичен проблем. Това е бизнес причината всички да сме тук.

Стъпка 2: Попълнете раздела за визията на продукта и пускането на продукта

Това позволява на екипа да получи яснота или да се освежи за това каква е нашата продуктова визия и как в момента сме дефинирали приоритетите си за развитие на продукта. Запишете изявлението Product Vision и коя е основната целева група. След това идентифицирайте няколко ключови продукта, които искате да доставите във всяка версия. Препоръчвам да попълните тези полета като екип и да не ги попълвате предварително. Той гарантира, че както технологичният, така и продуктовият екип участват в процеса на определяне на целите. Работете отляво надясно: идентифицирайте целите за първата итерация на продукта - големите функции, които са необходими, за да задоволят нуждите на вашите клиенти.

В нашия пример за приложение, нашата продуктова визия е „Да се ​​даде възможност за комуникация в реално време между хората, които живеят в моя квартал, за да се укрепи общността.“ След това в Продуктовите версии можем да кажем, че Версия 1 е „За да идентифицирате текущото си местоположение, покажете кой е наблизо и комуникирайте с техния имейл адрес“. V2 може да е „да покаже кой е наблизо и да позволи чат в реално време.“ V3 може да е „да се даде възможност за поверителност и осигуряване на приходи“. Тези повторения на продукта ще бъдат въведени в платното, както е показано по-долу. Поддържайте платното възможно най-просто, за да могат хората да видят голямата картина. Платното също е предназначено да улови дългосрочната визия. Имайте предвид, че това може да е първият път, когато технологичният екип вижда толкова ясна картина на вашия продукт, така че отделете достатъчно време, за да сте сигурни, че разбират всяко от изданието и придружаващите го изисквания.

Стъпка 3: Съобразете технологичната визия с продуктовата визия

Сега е време да получите принос от технологичния екип и да дефинирате тяхната визия как ще се развива технологичната архитектура. Започнете с Technology Vision, изявление, което очертава общата картина на развитието и което може да оцелее при промени в инструментите на доставчика. В нашия пример за приложението Technology Vision може да гласи: „Да използваме възможностите за геолокация на устройства, които предоставят информация за местоположението и да използваме безсервърни микросервизи, за да дадем възможност за облачно сътрудничество“ В момента не избираме конкретен инструмент. Помислете за Technology Vision като за голямата идея за това как технологията ще помогне тук и какви иновации се стремим да приемем, които ще дадат конкурентно предимство, както и технологична писта, която може да ни отведе до нашата визия.

Стъпка 4: Съобразете технологичните планове с целите на продукта

Тук гумата удря пътя. В стъпка 2 за всяка итерация на издаване на продукт бяха идентифицирани ключови характеристики. Сега трябва да дефинирате технологичния план за всяко от тези издания. Определете каква технологична архитектура и инструменти ще са необходими за поддържане на всяка от тези функции. Добре е да се идентифицират точните инструменти и да се получат технически. Ако е необходимо, можете да завъртите в бъдещи версии. Планът е екипът на технологиите да съобщи изрично какво ще трябва да направи.

Нека технологичният екип ръководи тази част и ги увери, че отговорите не трябва да са перфектни. Ако трябва да си отидат и да направят повече изследвания, те могат да направят това след срещата. Но целта тук е да завърши първата итерация на платното, която може да бъде актуализирана по-късно. Съвършенството е враг на успеха.

В нашия пример за приложение разглеждаме нуждите на продукта в полето Product Release 1. Въз основа на тези изисквания бихме могли да кажем, че Технологичният план 1 е „Разработете прогресивно уеб приложение, използвайки Ionic, за да активирате междуплатформеното приложение. Използвайте възможностите за геолокация на устройството. Синхронизиране с Firebase back end. Използвайте услугата за електронна поща SendGrid. “ Технологичният план и целите, описани тук, трябва да са достатъчни за постигане на целите на продукта. Уверете се, че екипът не е свръх инженеринг, когато целите на продукта не съществуват.

В тази стъпка най-накрая можем да видим силата на платното - така подреждаме екипите. Привеждаме в съответствие целите на продукта с технологичния план. А тази линия в средата? Това е интерфейс , които продуктовият мениджър трябва активно да управлява между екипите.

По подобен начин Технологичният план 2 би бил „Прилагане на удостоверяване на потребителя с помощта на оторизация на Facebook / Google, внедряване на чат в реално време с база данни на Firebase и интерфейс за чат.“ Технологичният план 3 ще бъде „Прилагане на поверителност / GPS скриване и методи за закупуване в приложение за надстройки на приложения.“

Процесът ще изисква от технологичния екип на вашата среща да допринесе за дискусията. Ще имате възможност всички идеи и прозрения да бъдат споделени и обсъдени и ще получите подреждане на екипа и бай-ин. Това е мястото, където хората от всички страни на екипите ще разберат нуждите, приоритетите и проблемите, които трябва да бъдат обсъдени и където ще разработите първоначални планове и споразумения.

расте ли музикалната индустрия

На този етап имате първата пътна карта на черновата на технологията, която съответства на продуктовата карта на продукта. Основните технологични задачи са изложени във визуален поток, който ще помогне на вашите екипи да знаят върху какво и кога да се фокусират.

Стъпка 5: Определете рисковете и ресурсите

И накрая, след като решите как ще изградите продукта от гледна точка на технологичната архитектура, е добра идея да обсъдите рисковете и ресурсите. В нашия пример бихме могли да кажем за Рискове: „Има шанс прогресивното уеб приложение да не е достатъчно бързо.“ Ако е така, бихме могли да се насочим към React или разработка на Native app. За ресурси ще ни трябват хора с набор от умения в „Ionic, PWA, геолокация и Firebase.“

Включването на тези елементи тук гарантира, че това резюме от една страница улавя основните елементи, които възникват от дискусията, и ще бъде полезно по-късно, когато прегледате платното отново.

Пълната картина

Ето завършен пример за платформата за технологични продукти въз основа на нашия хипотетичен пример за приложение по-горе:

Не трябва да се очаква, че платното трябва да бъде напълно завършено при първото движение. Може да не се съгласите като екип относно това какво е характеристика на продукта в сравнение с техническа възможност и къде да поставите какво на платното. Целта на платното е да инициира и постави в рамка дискусия, така че в края на сесията вие и целият екип да имате много по-добро концептуално споразумение за това как трябва да продължи развитието.

Този документ сега е ядрото на вашия план за развитие. Това е пътната карта за развитие на високо ниво и технологичният екип вече може да се възползва от това и да формулира своите по-подробни задачи за развитие, знаейки целите на бизнеса.

Заключение: Повторете платното на вашия технологичен продукт

Петте стъпки при създаването на платно за технологичен продукт са:

1. Дефинирайте показателите за успех
2. Попълнете раздела за визията на продукта и пускането на продукта
3. Съобразете технологичната визия с продуктовата визия
4. Съобразете технологичните планове с целите на продукта
5. Идентифицирайте рисковете и ресурсите

Много важно предимство на платното е, че то позволява на екипите да идентифицират „минималната“ технология, която трябва да се прилага или разработва на всеки етап. Той помага на продуктовия екип да осъзнае необходимите технологични усилия и всички предизвикателства, които предстоят. Развитието на продукта не се забавя от липсата на технически възможности, тъй като техническите планове са синхронизирани и виждат достатъчно стъпки напред. В примера с приложението бихме обучили нашия екип или ще намерим експерт по технология SignalR, докато се приближаваме до издаването на версия 1, така че да сме готови за версия 2, където това умение е необходимо.

Можете да изтеглите платформата за технологични продукти тук . Препоръчвам на екипите да извършват преглед на всяко тримесечие и определено при завършване на всяко издание. Чувствайте се свободни да модифицирате платното, за да отговаря по-добре на вашите нужди. Наистина би ми било интересно да чуя вашите отзиви за това как технологичното платно на продукта може да бъде подобрено.

Разбиране на основите

Какво представляват продуктовите екипи?

Екипът на продукта може да бъде междуфункционален екип, който е в състояние да осигури увеличение на продукта. Това би включвало продуктов мениджър, разработчици и др. Освен това продуктовият екип може да означава група хора, които доставят продуктови изисквания на екипа на разработчиците като продуктови мениджъри, бизнес анализатори, анализатори на данни и т.н.

колко трудно е да се научи

Какво представлява продуктовата стратегия?

Продуктовата стратегия определя какъв вид продукт трябва да бъде създаден за определен пазар или потребителски сегмент. Освен това стратегията трябва да дефинира как този продукт ще бъде пуснат на пазара.

Как измисляте продуктова стратегия?

Продуктовата стратегия се създава чрез провеждане на обширни пазарни проучвания, които разкриват нуждите на потребителите. Това може да се направи чрез анализ на данни, количествен анализ, разработване на MVP или други тестове.

Какво е технологичен екип?

Технологичният екип е група от хора с технически умения, които са необходими за постигане на някаква бизнес цел като разработване на продукт.