Bilang isang co-founder at isang paminsan-minsang freelance na tagapamahala ng produkto, taga-disenyo, at developer, nagtrabaho ako sa magkabilang panig ng talahanayan: bilang pinamamahalaan ng isang developer, at bilang isang tagapamahala na nagtatrabaho sa isang developer.
Kaya, kung ikaw ay isang tagapagtatag, tagapamahala ng produkto, o sinumang nagtatrabaho sa isang pangkat ng teknikal - Nais kong ibahagi ang ilang mga bagay na dapat gawin upang mapasaya ang iyong mga empleyado at gawing mas madali ang kanilang buhay.
Bakit abala? Buweno, bukod sa nais lamang na maging isang mabuting boss, mas madali ang buhay ng iyong tagabuo, ang mas mabilis at mas mahusay na magagawa niyang ipatupad ang mga tampok. At sa internet, kung saan gumagalaw ang oras sa bilis ng mga taon ng aso, siguradong isang kalamangan ito.
Narito ang mga susi sa tagumpay kapag nagtatrabaho sa iyong pangkat ng teknikal.
Unawain ang Pagkakaiba sa pagitan ng isang CTO at Lead Engineer
Makikipagtulungan ka man sa isang CTO o isang Lead Engineer, at mahalagang maunawaan na hindi sila kinakailangang magkatulad na tao.
Minsan mayroon kang isang kamangha-manghang CTO na hindi lamang teknikal, kundi isang mahusay na tagapamahala, tagapagbalita, at delegador. Ang mga uri na ito ay malamang na nais malaman ang lahat tungkol sa kung ano ang iyong pagbuo, kung ano ang wakas na layunin ay para sa gumagamit, at ang iyong pangkalahatang mga layunin sa negosyo. Magaling yan! Maniwala ka sa akin, ito ay isang pag-aari. Nurture ito.
Karamihan sa mga oras, bagaman, lalo na sa ekonomiya na ito ng mahirap na developer - magkakaroon ka ng isang Lead Engineer: isang tao na kamangha-mangha sa engineering ng isang produkto, ngunit hindi kinakailangang magkaroon ng mga kasanayan (o ang pagnanais) upang pamahalaan ang isang koponan at produkto.
Ang mas mabilis mong napagtanto kung anong uri ng tao ang kailangan mo (o nag-upa), mas mahusay na handa ka upang pamahalaan ang taong iyon at ang produkto.
Pag-aalaga tungkol sa Kung Paano ang mga Bagay
Ang mga nag-develop ay gumagawa, hindi mga makina. Kaya pakinggan ang kanilang mga ideya at siguraduhin na isinasaalang-alang mo ang mga ito - kahit na wala kang ideya kung ano ang impiyerno na pinag-uusapan nila kapag sinimulan nilang ibigay ang mga teknikal na termino. Hindi alam ang pagkakaiba sa pagitan ng ito at ang salansan? Magtanong. Gamitin ito bilang isang pagkakataon upang malaman. Dapat kang magkaroon ng hindi bababa sa isang pangunahing pag-unawa sa teknikal na bahagi ng iyong produkto.
Maging tiyak
Ito ay higit na kapaki-pakinabang sa iyong pangkat na pang-teknikal na magtalaga sa kanila ng mga tiyak, maliit na gawain - huwag lamang ibigay ang isang grupo ng mga pangungutya at sabihin sa kanila na magagawa sa pamamagitan ng Biyernes. Sa katunayan, dapat ikaw ang namamahala sa proyekto para sa kanila. Alamin kung paano gamitin ang software management software tulad ng Pivotal Tracker o Trello at subaybayan ang pag-unlad ng tampok na pag-unlad sa araw o bawat sesyon sa trabaho.
At suriin nang madalas, kapwa sa tao at sa pamamagitan ng iyong software management software. Ito ay mas madali upang maiwasan ang mga bagay mula sa pagpunta sa maling landas kung maaari mong mahuli ang mga ito sa tinidor.
Huwag Baguhin ang Iyong Pag-iisip Araw-araw
Alam ko, sa palagay mo malinaw ang tunog na ito. Ngunit kapag nauwi ka at nagbebenta ng iyong produkto araw-araw, ang pagdinig ng puna at mga brainstorming mga paraan upang mas mahusay ito - talagang madali itong bumalik sa mga bagong ideya sa lahat ng oras. Huwag gawin ito sa iyong koponan.
Tukuyin ang isang tiyak at maliit na bagay na nais mong itayo: isang Minimum na Mabubuhay na Produkto (o "MVP"). Ipagawa ang iyong MVP at handa nang itayo. At gawin itong maliit. Kung dinisenyo mo ang isang higanteng app, masira ito at magsimula sa isang bahagi. Ipadala ang iyong MVP-at pagkatapos ay baguhin ang iyong isip batay sa data.
Gayundin, kung wala ka pa, basahin ang The Lean Startup ni Eric Ries. Sundin ito - huwag lamang itapon ang mga cool na jargon sa mga kaganapan sa networking.
Itakda ang Mga Layunin, Hindi Mga Tiyak na Tula
Sa teknikal na mundo, ang mga deadlines ay hindi palaging gumagana. Kahit na ang pinaka-nakaranas ng developer ay nakakasira ng mga bagay-bagay, at tinantya kung gaano katagal ang magagawa upang ayusin ang mga bagay ay mahirap.
Talagang nasa ideya ako ng Tracker na masira ang mga tampok at magtatalaga ng mga puntos ng kahirapan, hindi oras. Markahan ang isang problema bilang "madali, " "medium, " o "mahirap, " at subaybayan ang pag-unlad sa halip na manatili sa mga deadlines. Pagtatalaga ng halos mahirap na mga gawain? Marahil maaari silang masira pa.
Kumuha ng isang Magaling na Disenyo
Nalulutas ng mga taga-disenyo ang mga problema at maaaring gawing mas madali ang proseso ng pagbuo ng produkto. Lalo na ang UX / UI (karanasan ng gumagamit at interface ng gumagamit) na taga-disenyo. Tinutulungan ka nila na malaman kung ano ang dapat magmukhang at kumilos tulad ng iyong produkto-piksel sa pamamagitan ng pixel, pakikipag-ugnayan ng gumagamit sa pamamagitan ng pakikipag-ugnayan ng gumagamit (isipin: Ano ang pindutan ng mag-click sa gumagamit? Saan ito sa pahina? Saan ito kukuha sa kanya?).
Hindi ito trabaho ng iyong developer. Seryoso ako. Ang trabaho ng iyong nag-develop ay ang pagsulat ng code - hindi idisenyo ang produkto. Ang isang mahusay na taga-disenyo ay makakatulong sa iyo na makatipid sa mga gastos sa pag-unlad, dahil tutulungan nila ang koponan na isipin at mahuli ang mga bagay na maaaring hindi napansin ng iba. Maaari din nilang imungkahi na gumawa ng simple ngunit malakas na mga pagbabago na gagawing mas madaling maunawaan at madaling gamitin ang iyong produkto.
Kasabay nito - tiyaking payat ang iyong taga-disenyo. Minsan hindi nagkakahalaga ng gastos upang bumuo ng pasadyang lahat. May pagkakaiba sa pagitan ng pansin sa detalye at pagiging isang diba. Kung ang iyong developer ay nagrereklamo tungkol sa isang disenyo - iyon ang tanda na kailangan mong ihinto, talakayin, i-tweak ito, at kompromiso.
Pagsubok, Pagsubok, Pagsubok
Kung nagmamalasakit ka tungkol sa iyong produkto - tulungan ang iyong developer na subukan ito. Ilang oras na siyang tinitigan niya. Bigyan siya ng isang bagong hanay ng mga mata. Purihin siya sa kanyang ginawa ng tama, at bigyan siya ng mga tiyak na gawain para sa kailangan pa ring gawin o maayos.
Ang mga nag-develop ay madalas na nagreklamo sa akin na ginugol nila ang maraming oras sa isang bagay at pagkatapos ay inilunsad ito sa mga bagay na nasira dahil walang nakakita. Tandaan, ito ang iyong produkto. At walang nagnanais na magtrabaho para sa isang taong hindi nagmamalasakit sa produktong inilalagay nila doon.
Magbayad ng patas
Ikaw ay isang negosyante, at makipag-ayos ang mga negosyante. Karaniwan, mas mahusay kaysa sa mga taong hindi pangnegosyo.
Kaya, mag-ingat.
Maaari kang makipag-ayos sa isang developer sa kanyang rate, ngunit kung ito ay makatuwiran, marahil ito. Tandaan na maraming mga ibang tao ang naroroon na handa at makapag-upa sa kanyang sinipi. At, kung naramdaman niya na siya ay wala nang napagkasunduan at hindi siya binabayaran kung ano ang halaga niya, ang mga pagkakataon ay hindi niya unahin ang iyong gawain sa ibang trabaho (o higit pa, mas nakakatuwang mga bagay). O, makakahanap siya ng ibang tao na babayaran ang kanyang rate, pagkatapos ay iwan ka na nakabitin. Paulit-ulit kong nakita ito.
Ang isang kahalili ay upang makipag-ayos ng isang rate para sa isang panahon ng pagsubok para sa isang maliit na tampok, at sabihin sa kanya babayaran mo ang buong rate kung maayos ang proyekto.
Magtiwala sa Iyong Koponan
Nagdududa ka ba sa mga oras ng pag-padding ng iyong developer o slacking off sa pamamagitan ng pagpunta sa pinakamalapit na biergarten? Alalahanin na kung hindi ka umarkila ng mga taong pinagkakatiwalaan mo at kung sino ang mas mahusay kaysa sa iyo sa isang bagay, hindi ka nag-aarkila ng mga tamang tao.
Tiwala sa mga eksperto na iyong inupahan upang gawin ang kanilang trabaho. Bigyan sila ng mga tool na kailangan nilang gawin ito, kabilang ang direksyon, kakayahang umangkop, silid ng paghinga, at awtoridad. At madalas suriin.
