Jak jsme začali šetřit čas a peníze s interním Stack exchange (Stack overflow) řešením

Co nás k tomuto nástroji vedlo?

Určitě nejsme jediná firma, která nemá dokonalou dokumentaci ke všem knihovnám, nástrojům a projektům. A i kdybychom takovou dokumentaci měli, pak by stejně nepokryla problémy, na které někdo narazí jako první. Je totiž nutné na ně nejprve najít odpověď. Teprve poté je možné jejich řešení zavést do knowledge base pro všechny další lidi, kteří na ně mohou v budoucnu také narazit.

Navíc jsme rozeseti po mnoha týmech, kancelářích a budovách, takže se nám nezřídka stává, že někdo v týmu A řeší problém, který tým B (sedící v jiné budově) úspěšně vyřešil již dávno. Ale obvykle z důvodu, že jim nestálo za to se o něm nikde zmínit, tráví nakonec několik lidí z týmu A hodiny času na vyřešení téhož.

Normální odpověď na potlačení tohoto problému je použít službu typu stackoverflow.com, ale jelikož významně využíváme na projektech naše interní knihovny a nástroje, tak bychom se tam přirozeně žádných odpovědí nedočkali, resp. v opačném případě bychom spamovali veřejné řešení čistě interními informacemi.

Rozhodli jsme se tedy pro nasazení podobného řešení pro čistě interní použití. Tentokrát, i když to bylo čistě ve vývojářské režii, jsme potlačili několik hlasů volajících po tom, napsat si takový systém sami. Rozhodli jsme se na základě menšího výběrového řízení, které mělo v zadání několik klíčových požadavků sesbíraných napříč vývojáři, pro hotové řešení Question2Answer s několika rozšiřujícími pluginy.

Začátek a rozšiřování záběru nástroje (prohřešky a code-review)

Řešení se poměrně rychle ujalo, máme založený strom kategorií (vývoj, ui, administrace a jejich rozpady na Scala, Java, PHP, Javascript atd.). U otázek se nám v zásadě daří díky odběru notifikací generovat a hodnotit řadu odpovědí a identifikovat ty nejsprávnější.

V průběhu času jsme dokonce rozšířili záběr řešení i na nové dvě kategorie a to “prohřešky”, kde autor otázku založí s výsekem nějakého nedokonalého kódu, který objevil, s otázkou, kde ostatní vidí chyby, či jiné neoptimální konstrukce. V odpovědích se pak identifikovaný problém rozebere a celá komunikace slouží ostatním, aby se podobným řešením ve svých projektech vyhnuli.

Druhou kategorií je pak žádost o code-review, což je obdobné použití, které ale narozdíl od reaktivních prohřešků někdo proaktivně vytáhne k proprání, jelikož si není jistý svým vlastním řešením a v odpovědích se pak dozví jak by měl lépe postupovat. Tím zároveň opět posloužil i všem ostatním, řešícím podobný problém aby snadněji dosáhli optimálního řešení.

Otázka, na kterou zatím neznáme odpověď je, zda tento obsah tvořený prohřešky a žádostmi o code-review nebude v čase příliš "ředit" primární obsah. Zatím převažuje názor, že když někdo hledá řešení svého problému a ve výsledcích se mu objeví i code-review vztahující se k jeho problému, tak je to spíše správně, jelikož se tam dozví minimálně související informace ke svému problému, spíše než by bylo na škodu probírat se ve výsledcích hromadami prohřešků. Ale teprve čas ukáže, zda nebude nutné prohřešky a reviews oddělit zvlášť od primárního zaměření.

Klíčové vlastnosti

K použitelnosti nám z vlastností tohoto řešení pomáhají zejména:

  • možnost přihlášení se Google účtem a tedy žádná další registrace
  • vcelku rozumně řešené možnosti notifikací - používáme zejména sledování kategorií (tedy javisté javu, kodéři UI apod.) a tagů (specialisté na hibernate můžou sledovat novinky přidané s tímto tagem)
  • zapojení interního vyhledávání do našeho celofiremního vyhledávače, čili není nutné hledat zvlášť v projektové dokumentaci, zvlášť ve wiki a zvlášť ve stack exchange
  • a samozřejmě body, které lidé sbírají za různé aktivity a podporují soutěživost :)
  • Na závěr by se určitě hodilo uvést kolik času a peněz jsme pomocí tohoto nástroje ušetřili. Bohužel je to velice složité změřit, jelikož nejde dopředu říct, jak dlouho by někdo řešil nějaký problém, kdyby na jeho hotové řešení nenarazil díky tomuto nástroji.

    Možná by tedy správnější název článku mohl být “Jak si myslíme, že jsme začali šetřit čas a peníze s interním Stack exchange (Stack overflow) řešením”.

    A jak je to u vás, používáte také nějaké nástroje na sdílení know-how, měříte jejich přínos, či řešíte zmíněné "ředění" obsahu?

    Článek obsahuje 4 komentáře

    • Petr

      1
      Díky za článek, myslím, že to je skvělý nápad.

      Zajímalo by mne, zda Vám to skutečně funguje podobně jako StackOverflow, tedy někdo se zeptá a za x minut/hodin/dní mu někdo jiný odpoví, nebo zda je to spíš ve smyslu: 'Měl jsem tento problém a chci se s ostatními podělit o řešení, protože si myslím, že na to taky narazí.' Tzn. skutečně se Pepa zeptá a Jarda mu odpoví, nebo Pepa popíše problém a pak sám i řešení? Asi hodně záleží na velikosti firmy. Nedokážu si moc představit, že bych u nás (7 lidí) čekal (nebo dokonce spoléhal) na to, že mi někdo odpoví. To radši jdu přímo za tím člověkem, o kterém vím, že bude umět poradit. Ale jako nástroj pro sdílení řešení (knowledge base) a k diskuzi o nich by to mohlo být dobré. Líbí se mi i kategorie 'prohřešky' a 'code-review'.

      Možná by Vám proti 'ředění' pomohl nějaký jiný nástroj speciálně jen na code-review. Ale tohle u nás budeme teprve řešit, takže neporadím.
    • Lukáš Voborský

      2
      Zdravím, jelikož developerů, pro které je toto řešení primárně zaměřeno, je tu několik desítek, tak nám funguje i přístup, kdy se tazatel dozví odpověď v použitelném intervalu minut až hodin.

      Zde tedy souhlasím, že s rostoucí "členskou základnou" použitelnost roste, nicméně není třeba zoufat. Jak to řešíte nyní v 7 lidech? Chodíte se zřejmě ptát těch nejzkušenějších (či jednoho nejzkušenějšího). A ten (hádám, resp. vídám to i v našich týmech) často opakovaně odpovídá na ty samé dotazy několika různých jedinců (kteří si to mezi sebou neřeknou). Čili i pro tohoto "guru" by mohlo být takové řešení přínosné - něco ve stylu, ano odpovím ti teď hned naživo tvůj dotaz, ale ty ho na oplátku zanes do nějaké takové znalostní báze, abych na něj hned zítra nemusel odpovídat někomu dalšímu (a tím ztrácel svůj tipuji velice drahý čas).

      Samozřejmě, nemá cenu zavádět takovýto, či jiný systém, pokud sedí vývojářský tým pohromadě v jediné místnosti.


      Zároveň jsme však zavedli takzvané "řečnické otázky", které si pokládá a zodpovídá sám tazatel, jelikož se domnívá že odpovědi budou užitečné i ostatním (či se chce pochlubit, co za složitý problém vyřešil). Tedy něco jako návod, ale zanesený do struktury interního stack overflow, kde ho každý má rychle po ruce.
    • laco

      3
      mozete dat zoznam rieseni ktore ste posudzovali?
    • Zdeněk Straka

      4
      Začínali jsme s tímto seznamem, vedeným vcelku vtipně jako dotaz na Stack Overflow: http://meta.stackoverflow.com/questions/2267/stack-overflow-clones

      Nicméně vzhledem k interním potřebám a požadavkům jsme velkou část odfiltrovali a skončili jsme u trojice

      http://meta.osqa.net/
      http://kunjika.libreprogramming.org/questions

      a finálně vybraným http://www.question2answer.org/