Като съосновател и случаен мениджър на продукти на свободна практика, дизайнер и разработчик съм работил от двете страни на таблицата: като разработчик, който се управлява, и като мениджър, работещ с програмист.
Така че, ако сте основател, продуктов мениджър или някой, който работи с технически екип - искам да споделя няколко неща, които да направите, за да зарадвате служителите си и да улесните живота им.
Защо да се притеснявам? Е, освен че просто искате да бъдете добър шеф, толкова по-лесен е животът на вашия програмист, толкова по-бързо и по-ефективно ще може да внедрява функции. И в интернет, където времето се движи със скоростта на кучешките години, това определено е предимство.
Ето ключовете за успеха при работата с вашия технически екип.
Разберете разликата между CTO и водещ инженер
Или ще работите с CTO или с водещ инженер и е важно да разберете, че те не са непременно един и същи човек.
Понякога имате невероятно CTO, което е не само технически, но и страхотен мениджър, комуникатор и делегатор. Тези типове вероятно искат да знаят всичко за това, което изграждате, каква е крайната цел за потребителя и общите ви бизнес цели. Това е страхотно! Повярвайте ми, това е предимство. Подхранвайте го.
По-голямата част от времето обаче - особено в тази икономика за разработчици - ще имате водещ инженер: човек, който е невероятен в проектирането на продукт, но не е задължително да притежава умения (или желание) да управлява екип. и продукт.
Колкото по-бързо осъзнаете от какъв човек се нуждаете (или сте наели), толкова по-добре ще сте подготвени да управлявате този човек и продукта.
Грижи се за това как стоят нещата
Разработчиците са производители, а не машини. Затова слушайте техните идеи и се уверете, че ги обмисляте - дори и да нямате представа за какво, по дяволите, говорят, когато започнат да обхващат технически термини. Не знаете разликата между този и този стек? Питам. Използвайте го като възможност за учене. Трябва да имате поне основно разбиране на техническата страна на вашия продукт.
Бъдете конкретни
Много по-полезно е за вашия технически екип да им зададете конкретни малки задачи - не раздавайте само куп макети и им казвайте да бъдат изпълнени до петък. Всъщност вие трябва да сте този, който управлява проекта за тях. Научете как да използвате софтуер за управление на проекти като Pivotal Tracker или Trello и проследете напредъка на развитието на функциите по ден или на работна сесия.
И се регистрирайте често, лично и чрез вашия софтуер за управление на проекти. Много по-лесно е да попречите на нещата да тръгнат по грешен път, ако успеете да ги хванете на разклона.
Не променяйте ума си всеки ден
Знам, мислите, че това звучи очевидно. Но когато всеки ден изпробвате и продавате продукта си, чувате обратна връзка и мозъчна атака начини да го подобрите - наистина е лесно да се връщате с нови идеи непрекъснато. Не правете това на вашия екип.
Определете конкретно и малко нещо, което искате да изградите: минимален жизнеспособен продукт (или „MVP“). Направете своя MVP спецификации и готови за изграждане. И го направете малък. Ако сте проектирали гигантско приложение, разбийте го и започнете с една част. Изпратете своя MVP - и след това променете решението си въз основа на данни.
Освен това, ако все още не сте, прочетете Lean Startup от Eric Ries. Следвайте го - не просто се хвърляйте около готин жаргон на мрежови събития.
Задайте цели, а не срокове
В техническия свят сроковете не винаги работят. Дори и най-опитният разработчик разгражда нещата и е трудно да прецените колко време ще отнеме, за да коригирате нещата.
Наистина съм в идеята на Tracker да разбие функции и да назначи точки за трудност, а не часове. Маркирайте проблем като „лесен“, „среден“ или „труден“ и проследете напредъка, а не се придържайте към крайните срокове. Възлагане на предимно трудни задачи? Те вероятно могат да бъдат разбити допълнително.
Вземете страхотен дизайнер
Дизайнерите решават проблеми и могат да улеснят процеса на изграждане на продукта много повече. Особено UX / UI (потребителско изживяване и потребителски интерфейс) дизайнери. Те ви помагат да разберете как трябва да изглежда вашият продукт и да действа - пиксел по пиксел, взаимодействие на потребителя чрез взаимодействие с потребителя (помислете: Кой бутон натиска следващия? Къде е на страницата? Къде я отвежда?).
Това не е ваша работа на програмист. Сериозен съм. Задачата на вашия програмист е да пише код, а не да проектира продукта. Един страхотен дизайнер всъщност ще ви помогне да спестите разходи за разработка, защото ще помогне на екипа да премисли и да хване неща, които другите може да са пренебрегнали. Те могат също да предложат да направите прости, но мощни промени, които ще направят вашия продукт по-интуитивен и лесен за използване.
В същото време - уверете се, че вашият дизайнер е строен. Понякога не си струва разходите за изграждане на потребителски всичко. Има разлика между вниманието към детайла и това да си дива. Ако вашият разработчик се оплаква от дизайн - това е знак, че трябва да спрете, да го обсъдите, да го настроите и да направите компромис.
Тест, тест, тест
Ако изобщо ви е грижа за вашия продукт - помогнете на програмиста да го тества. Тя се взира в това с часове. Подарете й нов набор от очи. Похвалете я за това, което е направила правилно, и й дайте конкретни задачи за това, което все още трябва да се направи или поправи.
Разработчиците често ми се оплакват, че са отделили тонове време за нещо и след това тя стартира с разбити неща, защото никой не ги е видял. Не забравяйте, че това е вашият продукт. И никой не иска да работи за някой, който не се интересува от продукта, който пускат там.
Компенсирайте справедливо
Вие сте бизнес човек, а бизнесмените преговарят. Обикновено много по-добре от нетърговските хора.
Така че внимавай.
Можете да преговаряте с предприемач за цената й, но ако звучи разумно, вероятно е така. Имайте предвид, че има много други хора, които желаят и могат да я наемат за това, което цитира. И ако се почувства, че е била договорена извън нея и не й се обезщетява това, което струва, има вероятност да не даде приоритет на работата ви пред друга работа (или над други, по-забавни неща). Или ще намери някой друг, който ще я плати, след което ще ви остави да виси. Виждал съм го отново и отново.
Алтернатива е да се договори тарифа за пробен период за малка функция и да й кажете, че ще платите пълната ставка, ако проектът върви добре.
Доверете се на вашия екип
Подозирате ли се в часовете си за програмиране на програмисти или отслабвате, като отидете до най-близката биергартен? Помнете, че ако не наемате хора, на които имате доверие и които са по-добри от вас в нещо, тогава не наемате правилните хора.
Доверете се на експертите, които сте наели да вършат работата си. Дайте им необходимите инструменти за това, включително посока, гъвкавост, стая за дишане и авторитет. И проверявайте често.
