sobota, 14 sierpnia 2010

Kaszmirowy sweterek informatyka

Kiedy na spotkaniu projektowym nie jesteś w stanie rozróżnić po ubiorze szeregowych przedstawicieli IT od eleganckich Kierownika Produktu i Kierownika Projektu, to może być sygnał, że z firmą coś jest nie tak. Kiedy firma ma za dużo pieniędzy, manifestuje się to nie tylko rozdętymi systemami, ale także przesiąkaniem świata menedżerów do świata informatyków.

Idziesz do kuchni i nie słyszysz rozmowy o optymalizacji wydajności albo użytecznych bibliotekach, tylko np. o quick winach, challengowaniu, celach premiowych i wdrażaniu inicjatyw polepszających komunikację. Na spotkaniu projektowym grupa średnio zorientowanych osób debatuje nad niezbyt złożonym technologicznie problemem. Grupa nie dochodzi do konsensusu więc zaprasza się jeszcze więcej osób i dyrektorów.

Paul Graham, znany popularyzator idei start-upów, w felietonie "What Happened to Yahoo" opisuje wynaturzenia, jakie zrodziły dla tej spółki łatwe pieniądze. Zwraca szczególną uwagę na odpływ kompetencji technicznych i zestawia to z przykładami firm takich jak Google czy Facebook, które potrafią kultywować "kulturę hakerską". Ostatecznie Yahoo oddał walkowerem rynek reklam w wynikach wyszukiwania Googlowi.


Pozwolę sobie podprowadzić fragment felietonu na zachętę:

In technology, once you have bad programmers, you're doomed. (...) Most technology companies eventually get taken over by suits and middle managers. At Yahoo it felt as if they'd deliberately accelerated this process. They didn't want to be a bunch of hackers. They wanted to be suits. (...) Why would great programmers want to work for a company that didn't have a hacker-centric culture, as long as there were others that did? I can imagine two reasons: if they were paid a huge amount, or if the domain was interesting and none of the companies in it were hacker-centric. Otherwise you can't attract good programmers to work in a suit-centric culture. And without good programmers you won't get good software, no matter how many people you put on a task, or how many procedures you establish to ensure "quality".

Brak komentarzy:

Prześlij komentarz