Како мали тим гради производе (а да не полуди)

Ниједна корпоративна фраза није повређена током писања овог текста.

Нас је четрнаест. Довољно мало да сви знају на чему ко ради, али довољно велико да не можете да импровизујете без икаквог процеса.

Ова величина је чудна. Превелика за „хајде сви на позив да се договоримо“, премала за одељења, менаџере и формалне хијерархије. Морали смо да смислимо како да на овој величини заиста градимо производе и, искрено, још увек смишљамо.

Шта заправо градимо

Тренутно радимо на две главне ствари:

1. Arheev: наша HR платформа за компаније у расту. То је производ који градимо за себе (и за друге којима треба).
2. Пројекти за клијенте: радимо развој по мери за стартапе и компаније којима треба техничка експертиза коју немају у кући.

Жонглирање обома је понекад хаос. Таман зађемо дубоко у нове функције за Arheev, а онда се на клијентском пројекту појави критичан баг и пола тима пређе на њега. Или испланирамо спринт за клијента, па схватимо да Arheev-у хитно треба нешто за демо следеће недеље.

Са четрнаест људи нема решења типа „одвојени тимови“. Сви дирају све.

Како заиста доносимо одлуке

У великој компанији постоје процесни документи и ланци одобравања. На нашој величини то је претеривање.

Уместо тога, имамо једно правило: ако мислите да нешто треба урадити, направите прототип.

Не „закажите састанак да о томе разговарамо“. Не „напишите предлог за разматрање“. Само направите грубу верзију и покажите је тиму.

Ово звучи хаотично. Понекад и јесте. Али зато брзо напредујемо и брзо гасимо лоше идеје. Далеко боље него две недеље расправљати о нечему на састанцима, па то изградити и схватити да не ради.

Марко (наш руководилац инжењеринга) дошао је из фирме где је свака измена захтевала три нивоа одобрења. Каже да је, кад му је неко у Norveon-у први пут рекао „само испоручи и види шта ће бити“, помислио да је то тест.

Није био. Заиста верујемо да свако од нас може сам да процени.

Петком извештај о неуспесима

Сваког петка имамо стални састанак на ком људи деле шта те недеље није успело.

Не успехе. Неуспехе.

Пуштање у рад на Azure-у које је срушило продукцију. Функција коју смо направили, а корисници је мрзе. Рефакторисање које је перформансе погоршало уместо да их побољша. Састанак с клијентом који је кренуо наопако.

У почетку су људи нерадо делили неуспехе. Сада је то најкориснији састанак који имамо. Далеко више научите из „ево шта сам покварио и како сам поправио“ него из „ево шта је добро прошло“.

Када је јуниор програмер био у праву

Док смо правили Arheev, недељама смо дизајнирали распоред контролне табле. Више итерација, много расправе о хијерархији информација и корисничким токовима.

Онда је неко новији у тиму (ко је на већини састанака ћутао) гурнуо на staging окружење прототип који је одбацио цео наш приступ навигацији. Просто… потпуно другачије.

Прва реакција је била „ово руши све наше дизајнерске обрасце“. Друга реакција, након што смо то заиста користили, била је „чекај, ово заправо ради боље“.

На крају смо испоручили њихову верзију. Требало је још око две недеље да се дотера, али суштинска идеја, која је дошла од некога ко није учествовао у нашим ранијим расправама и није делио наше претпоставке, решила је проблем боље од нашег „експертског“ приступа.

Поука: кад сте нови, понекад још нисте покупили све погрешне обрасце.

Ствари које се не скалирају (а ми их ипак радимо)

Са четрнаест људи и даље можемо оно што веће компаније не могу:

Сви прегледају свачији код. Не само сениори који прегледају јуниоре. Сви виде свачији рад. То значи да преглед кода понекад траје дуже, али и да се знање брзо шири.

Испоручујемо директно у продукцију. Нема посебног тима за пуштање у рад, нема одбора за одобравање измена. Ако сте то направили и прошло је тестове, можете да га поставите. Ово ужасава људе из већих компанија. Нама је у реду.

Сви разговарају с клијентима. Нема „тима за односе с клијентима“ који штити програмере од корисника. Ако сте направили функцију, можда ћете баш ви да је демонстрирате или дебагујете с корисником. Неефикасно је, али тако се научи шта је заиста битно.

Шта се дешава кад ово не ради

Није све савршено. Неке ствари на нашој величини просто… не ваљају.

Силоси знања и даље настају. Чак и с прегледима кода и заједничким пројектима, једна особа на крају постане „она која зна како се пушта у рад“ или „она која разуме ток плаћања“. Кад је на одмору, ствари успоре.

Политика и даље постоји. Мањи тим не значи да нема неслагања или повређених осећања. Само имамо мање места да се од њих сакријемо.

Раст је чудан. Премали смо за специјализоване улоге, а превелики да сви раде све. Да запослимо још једног програмера генералисту или нађемо специјализованог дизајнера? Погрешан избор и месецима смо неуравнотежени.

Немамо решења за све ово. Само смо свесни да постоји и трудимо се да их не погоршамо.

Зашто је ово битно за производе

Начин на који радимо директно утиче на оно што градимо.

У Arheev-у (нашој HR платформи) можете да прилагодите практично све. Токови рада, дозволе, поља података, извештаји: све се подешава. Не зато што смо планирали да направимо „најфлексибилнији HR систем“, него зато што тако радимо интерно.

Мрзимо кад нас терају у круте процесе, па смо направили алат који не тера кориснике у круте процесе.

Да ли је већи, структуриранији тим могао да направи нешто слично? Можда. Али би требало више састанака, више планирања, више слојева одобравања. Док би они испоручили, тржиште би се померило.

Са четрнаест људи можемо брзо да напредујемо јер лоше идеје немају где да се сакрију. Ухвате се у прегледу кода, или на петковом састанку о неуспесима, или кад неко покуша заиста да користи функцију и схвати да је ужасна.

Где смо

Нисмо открили савршен начин да се граде производи. Нико није. Само делимо шта нама функционише на овој величини, у овој фази.

Нешто од овога ће пући како будемо расли. Нешто већ не ради онако добро као кад смо били мањи. Прилагодићемо се, или нећемо, и о томе ћемо такође писати.

Питајте нас поново за годину дана и одговор би могао бити другачији.