Ну и соответственно, предотвращение такой ситуации становится Большой головной болью владельца .
И если вдуматься, ситуация абсолютно аналогичная тому, как выкидывают посредника в случае если он перестает приносить выгоду.

Да, кстати, чтобы расставить все на свои места. Я не верю, что в exUSSR можно нормально эту проблему решить в легальном поле, так как попадание в суд, даже в виде обвиняющей стороны длинный и болезненный процесс. Ну и решение ее в нелегальном поле – а-ля “послать двух парней с паяльником – пообщаться” не наш метод тоже.

В целом есть три направления, в которых надо двигаться.

а) Контракт с заказчиком

Да, программисты не бояться того, что их засудят. Но заказчики, находятся в правовых странах, да и терять им есть гораздо больше.
Поэтому контракт в котором сказано о том, что никаких бизнес отношений с сотрудниками вашей фирмы в течении X лет просто необходим.

б) Нормальные отношения с своими подчиненными.

Нельзя сказать, что это полностью решает проблему, но явно уменьшает ее вероятность. В большинстве случаев, уводят проект именно те, кому наступили на любимую мозоль, а потом станцевали на ней джигу.

в) Компания (как посредник) должна быть полезна для заказчика.

Вот этот пункт достаточно сложны. Чаще всего все IT компании, которые делают проекты фактически предоставляют услуги, которые составляют 100% их пользы. Чаще всего нету особо дорогого оборудования, которые отделившиеся программисты не смогли бы себе позволить.

Одна из хороших идей, лицензирование им (даже за бесплатно) какие-то из своих библиотек. Эта та самая Intellectual Property, которая будет являться дополнительной пользой.

г) Желательно не держать все яйца в одной карзине. Например, менеджер проекта с вашей стороны, чтобы работал с менеджером с той стороны, а с ваш бухгалтер (или вы) работали с владельцем/финансовым директором с той стороны.

Проекты чаще всего уводятся именно тогда, когда с той стороны владелец уже отлично знает менеджера или программиста и этот менеджер/программист ему предлагает “урезать расходы” путем работы напрямую.

Только вот вывод из этого люди почему-то делают обычно не правильный.

Логичный вывод – если фирма не подходит под процесс, то можно либо найти другой процесс (под который подходит), либо если таки процесс очень ценный – то таки можно и переделать фирму.

Но есть еще и третий – самый худший вариант и о нем то и хочу написать.

Жил да был Вася, крутой чувак, у которого был дом с гаражем. И вон он решил себе купить немеренно крутую машину и выбрал Хаммер. Купил, приехал домой, а блин, машина в гараж не влезает на сантиметров 50. Ну, подумал, подумал и решил… А хули там… Если 50 сантиметров спереди оттяпаю, то ничего плохого с машиной не случится. И так выглядит уродливой уже. Ну, сказано – сделано. Хряп, нету 50 см, включая радиатор, аккумулятор, кусок движка и кучу прочей радостей. Блин…. не едет зараза. Ну пригласил механиков, кое как они на силу все заменили, назад присобачили. Ну ладно, если спереди не вышло, отрубим сзади. Хряп… Пробуем – ура… едет… Но как-то без глушителя, громкость как у реактивного самолета, плюс надоело выпадающие сзади сумки собирать. ok, переделываем выхлопную трубу, чтобы в правый бок шла, сзади навариваем шит, чтобы вещи не выпадали. Уже лучше, но из-за дыма из выхлопной трубы (каталитический конвертор тожи оттяпали) все стелка сбоку черные не фига не видно, плюс воняет постоянно. А сумки теперь сзади положить нельзя, только через салон запихивать приходится. Ладно, выхлопную трубу делаем подлиннее, так что она теперь справа на 30-40 торчит, а слева сзади прорежем дырку, через которые вещи можно доставать.  Труба правда теперь по асфальту бьется и мешает ехать правому ряду. Плюс, на парковке до окошка слева с вещами добраться не удасться. Переносим окно на крышу, выхлопную трубу загибаем, выводим на верх. Теперь правда машина похожа на небольшой паровоз 19 века, порезанная спереди и сзади, запаянная, с трубой сверху, с окном для того, чтобы класть вещи на крыше… Но зато она классно влазит в гараж.

Товарищи, искренне вас прошу, если вы увидели хорошо работающий процесс, который обкатывали и обкатывали, ну не надо отрезать от него 50 см (особенно не понимаю, что же вы отрезаете).

В прошлой статье я остановился на мае 2007 года.

Событие того мая, которое очень серьезно повлияло на фирму, было уходом нашего самого крупного заказчика. Такие события очень часто убивают небольшие фирмы мгновенно. Большинство фирм до 10 человек буквально живут одним заказчиком и при первом же неудачном движение, они остаются с кучей людей которым надо платить зарплаты и без возможности быстро (да и медленно) найти заказы, чтобы полностью загрузить даже часть людей.

Почему ушел заказчик? Хороший вопрос. Там много чего намешано было – то, что я был и сотрудником и владельцем provider’а и часовой пояс, и консолидация offshore активности и не слишком удачные с технической стороны последние несколько месяцев. Но, ключевым пунктом я бы сказал являлось то, что мы просто загнали себя в угол предоставляя им только Palm разработку(которая к тому времени была уже откровенно не актуальной).

Дальше, пошла жестокая борьба за выживание. Мы начали пытаться найти любые проекты, чтобы закрыть брешь в бюджете и загрузить людей. Естественно, из разряда медленное развитие фирма перешла в режим  постепенного разваливания.

В этот момент, я пытался активно продавить сделку, чтобы нас купили как отдел разработки для одной США компании. Но, хоть и мы и покупатель хотели броситься друг другу в объятья, одна мелочь в результате сорвала сделку. А мелочь состояла в том, что денег у той компании особенно и не было и все ее надежды у нее были на получение инвестиций. Инвестиции они не получили, как результат не только нас не купили, но и закрыли свой небольшой офис.Собственно это и было причиной почему они так были заинтересованы. Для них потенциальная покупка нас был хороший пункт того, как можно было показать инвесторам, что они собираются эффективно тратить деньги.

Где-то в сентябре 2007 я приезжал в Украину и все еще давал речь о том, что хоть сеячас тяжко, но мы все еще движемся в светлое будущее. Хотя, мягко говоря, я сильно в этом сомневался.

В целом сформировали несколько направлений выбирания из этой ситуации – активный поиск проектов, разработка продуктов и попытка поиска инвестиций (в штатах). На данный момент, я понимаю, что все эти действия были как мертвому припарки.

Если мы пытаемся активно найти проекты, то это значит одно из двух. Либо мы раньше плохо искали, причем сами не зная, что мы искали плохо. Либо если мы искали хорошо, то вероятнее всего слово “активизация” ни к чему особо не приведет.

Разработка продукта – это вообще не решение. Продукт – это инвестиция, которая принесет плоды дай бог через несколько лет. То есть решать ею бюджетные проблемы невозможно.

Поиски инвестиций, опять же, были абсолютно не актульаны из-за моего слабого английского языка, малого количеста связей и времени, физического расположения бизнеса вне штатов и отсутствия вразумительного бизнес плана.

Ну и где-то к 2008 году, я опустил руки. Моя проблема была в том, что по большему счету я фирмой занимался в режиме хобби. То есть денег она мне не приносила, хотя предположительно я мог бы брать какой-то % от прибыли или выставить себе зарплату, но это были бы абсолютно смешные цифры относительно зарплаты программиста, которую я получал в штатах. В основном я работал на какую-то светлую перспективу (а-ля нас купят как отдел разработки и я стану менеджеров всего этого дела с стороны штатов). При этом, я тратил кучу времени на дела своей фирмы. И собственно говоря, осознав, что мое хобби не только не приносит мне денег, но еще и напрягает меня , я решил выходить из режима активного управления.

Скажу также, что поверх этой и так непростой ситуации вплетались нотки того, что бизнес семейный, что добавляло эмоциональность к любым принимаемым решениям.

К середине 2008 фирма серьезно ужалась с ее пика в середине 2007 года. Продукт по большему счету так выпустить и не удалось, так как он не был правильно бюджетирован, а разрабатывался по остаточному принципу. Естественно, никаких инвестиций я и подавно не нашел.

И где-то к этому моменту мой брат решил закрывать бизнес, так как в течении нескольких месяцев фирма постоянно была в минусах и тривиально стало не хватать финансов для продолжения работы.

Но, в последний момент нам таки улыбнулась удача и я узнал, что компанию где работает директором один мой друг собирается купить большая компания. А так как покупаемая компания тоже в Харькове и тоже занималась мобильными разработками, то мы поговорили с ними и они предложили купить нас, чтобы подороже продаться большой компании. Ну и мы ударили по рукам. Единственное “но” было то, что учитывая наше положение (либо полное закрытие фирмы, либо продажа) мы были в плохой позиции для торговли и конечная цифра была очень далека от того, что можно было получить при аналогичной сделке только в хороший для фирмы момент.

В целом, на этом история фирмы закончилась. Если быть совсем точным, то история скорее отделилась от меня, так как торговую марку мы передали небольшой группе разработчиков, которая выделилась из нашей фирме при ее покупке.

Фух… Если честно, даже пиша этот текст слегка поднапрягся, так как те события были достаточно нервные. Но, теперь выдохнув можно спокойно сделать разбор полетов. Тут на самом деле просто поле для работы.

- Первую вещь, которую я хочу сказать, что крупные проблемы надо не преодолевать,  а пытаться их не допускать.Ситуация с уходом крупного заказчика классическая. Соотвественнно нужно “активизировать” гораздо раньше чем когда он ушел. И хотя мы и двигались в нужном направлении, но двигались слишком медленно. Я уже писал, в одной из статей, что гужно одновремено увеличивать объем заказов, а с другой стороны главного заказчика держать в максимально довольном состоянии.

- Вторая вещь, это то, что любые долгосрочные проекты (а-ля продукт), нужно начинать когда все хорошо, а не когда все плохо.  Кстати, я это уже когда-то описывал принципом “Играй когда выигрываешь“.

- Третья вещь, это то, что все отношения с вашими партнерами по бизнесу должны быть задокументированы(а-ля кто за что отвечает и что делается при выходе из бизнеса). Хоть это и неприятно обсуждать только стартуя бизнес, зато экономит гигантское количество нервных клеток потом.

А вот теперь к самому интересному. Что же все таки мы могли сделать?

Сразу скажу, что выбраться на белом коне из такой передряги шансов ну фактически нету. Любые пути решения будут сопряжены с большими рисками. Поэтому скорее я пытаюсь судить о том, какие пути обладали меньшим риском и большим выигрышем, но естественно самый лучший из путей мог завершиться провалом в тот момент, когда не самый эффективный завершиться удачей (как и прозошло).

И естественно я пытаюсь базировать все решения на нынешних знаниях, но тогдашних возможностях.

На данный момент я вижу три наиболее перспективных на тот момент пути

а)  Постепенный слив фирмы

Этот путь я высказывал и тогда. Он является наиболее пессимистичным. В смысле, если мы уверены, что впереди нас ничего хорошего не ждет и мы пытаемся просто вынять как можно больше денег из бизнеса пока он загнется.

Постепенно увольнять людей, которые не работают на активных проектах. Вынимать из фирмы всю получению прибыль. Продавать все пассивы (лишние компы, устройства и т.п.). В этот же момент постепенно повышая цены на работу заказчикам, чтобы компенсировать повышение зарплат.

Само собой, люди бы достаточно шустро побежали бы в таких условиях. Думаю лучше всего было бы договориться с несколькими ключевыми людьми о том, что им будет выплачен бонус, если они дождуться окончатльное закрытие.

Ясно, что с такой стратегией много с фирмы не получишь, но все равно больше чем в случае полного вылета.

б) Реорганизация

В случае если есть надежда на светлое будущее и  желание побороться, то пожалуй реорганизация самый лучший метод.У нас были две основных проблемы – много людей при нехватке проектов и работа над мелкими и дешевыми проектами.

Основная идея следующая, увольняются лишние люди, выкидываются лишние плохонькие проекты. На всех проектах постепенно подымается рейт додостаточного выского (позволяющего иметь нормальную маржу прибыли), включая дополнительные увольнения и людей и заказчиков если проекты не удается перевести на высокие рейти.

В целом переход от режима – “мы делаем все что угодно для мобильных дешево и сердито” и попытки накормить тремя хлебами всю фирму в режим “мы делаем средне по цене и качественно” и медленный и верный рост и постоянный контроль маржи прибыльности.

Естественно в начале такой режим смог бы поддерживать гораздо меньшее количество народу, но на долгосрочной перспективе – он более эффективен, при высоких зарплатах программистов.

Пришло таки время написать о чем же я писал все это время.

В самом простом виде, я бы сказал, что когда ты прочищаешь мозги на одну и ту же тему три раза Васе, два раза Пети. А потом тебе  надоедает прочищать мозги всем им по отдельности и ты пишешь документ, рассылаешь всем и говоришь: “Делать надо так как написано в этому документе и теперь не отнекивайтесь, что вам об этом никто не говорил и нету четкого описания как делать”. Так вот, записанная последовательность, того чего делать и чего не делать и есть процессы.

Конечно, процесс может быть таки и не записан. Но пока он не записан, найдется, таки Коля, который все сделает наоборот и потом искренне будет удивляться, почему ему устроили темную.

Дальше больше. Для каждой компании есть свой оптимальный размер процессов. Когда вы делаете софт для космического корабля, то любой commit должен быть просмотрен  кучей людей, для него должно быть куча разнообразных тестов, он должен быть правильным по куче стандартов. То бишь, там тома с описаниями их процессов. И наоборот, для конторы из одного человека, двух-трех процессов (а-ля, весь код в SVN, все баги в bugtracker) должно хватать. Ну и естественно, если компания выбирает неправильный уровень, какое количество процессов ей нужно, то либо в ней все будет делаться на коленке (и по ходу разваливаться), либо в ней что-бы пукнуть, нужно будет подписать пять обходных листов.

Ну и естественно, процессы бывают разные. Например связанные с наймом и увольнением – в которых записано вещи типа создание и удаление account’ов и т.п. Есть процессы для разработки – как branch’ить код, каков жизненный цикл ошибок, откуда приходят задачи и куда посылать того, кто их принес.

Вот такие вот пироги с котятами.

- организация совещаний

- соотношение менеджеров и исполнителей

- американский миф о команде

Итак по поводу совещаний. Я малехо удивлен, что фактически не в одной организации не проводятся нормально совещания, хотя в штатах, даже на простейших курсах, которые я проходит (Business communication для людей у которых английский – второй язык) рассказано как их разумно вести.

Частенько, особенно крупные и серьезные совещания, похожи на борьбу без правил – смешиваются в кучу кони, люди, все что-то пытаются сказать, мысль куда-то постоянно кочует, одно и тоже пережевывают по семь раз, общение разбивается на какие-то подгруппы. В целом твориться полная кутерьма.

А теперь быстренько по пунктам, что нужно для толкового совещания:

а) Длительность митинга должна быть обозначена заранее.

б) Вопросы, которые обсуждаются на митинге должны быть определенны заранее. А также нужно определить, желаемый тип результатов – решение, список идей, мнений или что-то другое.

Кстати, оба этих пункта озвучиваются и до митинга и повторяются в самом начале митинга.

в)Должен быть координатор совещания.

Это человек, который следит за тем, чтобы всем давали высказаться и не перебивали, возвращал обсуждения в запланированное русло и главное, если обсуждение вопроса затягивается, останавливал обсуждения и принимал решение о вынесение обсуждения деталей на отдельное совещание. Плюс, чаще всего, такой человек еще и ведет записки – сгенерированные идеи, принятые решения, возникшие дополнительные вопросы.

в) Должен быть человек, который имеет право принимать решения. Особенно, это важно если совещание собрано именно для принятия решений, а не для генерации идей. Я, вообще, очень сильно настаиваю на то, чтобы в компании было достаточно четкое разделение прав, ответственностей и полномочий. Так вот, должен быть человек, который может авторитарно сказать – мы идем путем A, а не путем Б.

г) В конце  митинга, проходится еще раз по плану и по выписанным решениям, идеям и действиям, которые надо сделать после митинга.

Усе… Этого достаточно, чтобы совещания не были местом спячки и разгребания накопившейся непрочитанной почты, а местом где собираются, чтобы делать что-то полезное.

Слава богу, что в IT на территории exUSSR пока не сильно прижился этот американский стандарт.

Второе, что я хотел сказать – это соотношение менеджмента и  исполнителей. Кстати, оказалось я об этом уже говорил тут. Хотя со мной и не согласились, но я считаю, что у чистого менеджера не должно быть больше чем 7 прямых подчиненных, но и меньше чем 4-5 тоже не должно быть. Как только вы обнаруживаете, что у вас 4 программиста, 3 тестировщика, 1 project manager и 2 product manager, 1 director, 1 CEO, 1 CFO, 1 CTO и т.п., то значит в королевстве датском, не все в порядка, так как общее соотношение по фирме выходит один исполнитель к одному менеджеру. Чаще всего этим болеют молодые компании, которым ну оооочень хочется, выглядеть большими и серьезными. Но, чаще всего, это проходит, как только становится видно что деньги утекают с какой-то сумасшедшей скоростью.

И третье – американский миф о команде. В нескольких книгах читал, да и в жизни видел, как здесь любят идею – собери хорошую команду, а хорошая команда тебе решит любые проблемы. Так вот… фигня это. Не совсем конечно фигня, но достаточно сильно. Ясно, что с хорошей командой легче решать все проблемы, чем с плохой. Однако, во первых команда – только часть всего, есть еще деньги, есть процессы, есть заказчики, есть идея, есть продукт или услуга построенные на этой идее, есть контакты, есть удача и т.п. И абсолютно не стоит надеяться, что одной хорошей командой удастся заткнуть все дыры.

Из новых ощущений
- Очень понравилось то, что не пытаешься планировать в какие-то бесконечные дали, а решаешь текущие проблемы, оставляя будущие проблемы на будущее (причем это относится как к product managment’у, так и к программированию).
- Понравились burnchart’ы – гораздо более объективная и простая методика видеть, как движется проект (по сравнению с нереально тяжким и неточным MS Project).

А вот теперь то, что НЕ понравилось

- Узаконенное не планирование архитектуры.

Молодые/плохие разработчики с удовольствием работают в пределах user story. Приемочные критерии пройдены, а остальное их не сильно волнует. Проблема возникает в том, что они могут писать код, который является полным говном. И когда, даже внутри того же спринта сталкиваешься с другой user story в которой нужно использовать их код, приходится – разобраться в нем, отрефакторить, проверить, что старая US не поломана и что новая сделана. И это в результате выходит дольше, чем сделать хорошо сраз.

В основном проблема тут в том, что задачи (например продумывание архитектуры) вероятность которых выполнения в этом спринте больше определенной нельзя откладывать на потом.

Впрочем проблема тут не только в Скруме, но просто в Скруме она узаконена.

Вторая вещь, которая меня напрягает насчет Скрума, что менеджеры ее могут считать волшебной палочкой, которая решает все проблемы. Типа “вот вам команда Скрум, а теперь делайте все сами, а я будут только наблюдать, чтобы оно шло внутри этого процесса”. Все таки, Скрум – это всего лишь методика управления проектами. Вне этой методики остаются вопросы мотивации, бизнес вопросы, улучшение процессов, технические вопросы и т.п. Ну и соответственно, если забить на эти вопросы – то ждать хороших результатов не стоит.

Хотя как показала практика, не один я такой. В Google ищем “QA engineer” – получаем 1M результатов, “QC engineer” – 200k. Судя по всему, большинство таки людей хотя сказать QC используют QA.

Но, я собственного говоря не об этом. Я совсем о другом.
Почему-то в последнее время повеяла такая мода программистам побольше QC задач подкидывать и пытаться размыть границу между программистами и QC engineer (я дальше буду писать тестировщиком, хотя это и не идеально выражает то, что делают QC engineer’ы).

Проще говоря, когда менеджер говорит, ты код напиши и оттестируй полностью, чтобы после тебя тестировщам не надо было тратить много времени.

Или например, в Scrum, есть попытка ввести понятие Team member, без разделения на программиста и тестировщика. И типа, что нужно то и делай для окончания задачи.

Честно говоря, я не в восторге от обоих инициатив. Разобью по пунктам, собственно в чем состоит мое недовольство.

а) Разделение труда

Достаточно странно, что везде идет разделение труда для повышения эффективности, тут же наоборот начинают смешивать труд.

б) Квалификация

Квалификация среднего тестировщика может быть (и обычно бывает) гораздо ниже чем у программиста.

Само по себе это ничего не значит, но влияет на следующий пункт.

в) Стоимость работы

Спрос на программистов и более высокие требования к квалификации удерживают зарплаты программистов выше чем зарплаты тестировщиков.

Можете бросаться в спор. Мне уже пытались доказывать обратное. Однако, цены на сайтах по предложений работы подтверждают именно мою теорию.

г) Односторонняя взаимозаменяемость

Да, программист может выполнять тестирование и достаточно легко может научиться писать планы тестирования и придумывать стресс тесты.

В обратную сторону, тестировщик чаще всего либо не может программировать вообще, либо является очень слабым программистом.

Опять же из этой асимметрии следует, что программисты должны таки работать над той задачей, которую тестировщики не могут решить.

В личных спорах мне говорили, что я типа зараза пытаюсь программистов выделить в высшую касту и что типа это ужас как плохо. На самом деле никакой высшей/нижшей касты нету – есть работа, которую делают и программисты и тестировщики и программисты просто (как по мне) являются более дорогим ресурсом.

Никаких супер привелегий у них нету, просто они делают работу которую тестировщик не умеет делать.

Как пример, нейрохирург вполне может вполне знать педиатрию. Но это же не значит, что он должен работать по этому поводу педиатром.

Суммируя. В целом, я не против некоторого количество тестирования на стороне программистов, которые уменьшает суммарное бюджет необходимый для доведения до ума. Но я категорически против того, когда из разряда “некоторое количество” это пытаются перевести в раздел – программист обязан делать полное регрессионное тестирование.

Дописал большой P.S.
Дисскусия в нескольких ветках упала в сторону, кто быстрее выучиться программист – тестировщиком или тестировщик программистом.

Откинем вопрос, хотят ли они учиться и примем за данность, что у обоих есть голова на плечах.

Плюс, сразу выкинем из рассуждения фразы типа “я вот знал тестировщика, который стал хорошим программистом, а наоборот не знаю ни одного”.

Мы будем говорить о статистической сложности переучивания, а не разбирать конкретный пример Васи или Пети.

Возьмем двух человек
а) Хорошего программиста
б) Хорошего тестировщика

Начнем с того, что хороший тестировщик вполне может не уметь программировать вообще (оставим на секунду автоматизированное тестирование за бортом). Он может заниматься написание планов тестирования, стресс тестированием, обучение молодежи как тестировать,тестировать безопасность, тестировать usability и т.п.

То есть, тестировщик знает как тестировать, но при этом легком может не иметь даже базовых знаний программирования.

В обратную же сторону -хороший программист НЕ может работать без базовых знаний тестирования. Он в общих чертах понимает, что такое план тестирования (просто за X лет работы он уже с ним не раз сталкивался), он делает минимальное тестирование сам перед отдачей тестерам. Я не говорю, что программист отлично понимает, но базовые понятие у него уже есть.

Таким образом, когда программиста нужно обучить тестированию, то по большему счету ему нужно углубить свои знания в
а) Стресс тестировании
б) Почитать несколько книг по планированию тестирования
в) Поменять мышление, для того, мыслить не с точки зрения “вот, что надо сделать, чтобы оно работало” а на “вот, что надо сделать, чтобы оно НЕ работало”.
г) Изучить некоторое количество инструментов для тестирования
д) Потестировать, чтобы разобраться что правильно, а что неправильно

То есть, как по мне, база знаний необходимая тестировщику не слишком большая, частично программист ей владеет. Ему нужно ее углубить и получить опыт.

Теперь тестировщику нужно обучиться программированию.
И вот тут база оказывается достаточно большой
а) Изучить основы программирования
б) Изучить язык программирования
в) Изучить API операционной системы/browser/базы данных
г) Изучить инструменты для программирования
д) Изучить такие вещи как ООП
е) Пописать программы, чтобы понять, что правильно, а что неправильно

То есть база знаний больше. А знание основ этой базы у тестировщика меньше.

Проблема в сложности изучения программирования (по сравнению с тестирование в двух вещах)
- В программировании гораздо больше информации нужно просто запомнить, которая не поддается логическому объяснению (на начальных этапах учебы). В тестировании же больше вещей логичны с самого начала
- В программировании результат работы гораздо медленней становится видим (например можно неделю работать над кусочком программы) и поэтому ошибки и опыт накапливаются медленнее.

Уже через неделю программист может выполнять простые элементы тестирования на __РЕАЛЬНЫХ__ (это ключевое слово) проектах.

В обратную же сторону, тестировщик сможет в этот момент только учиться на маленьких программках, которые не являются настоящими проектами. И только через долгое время сможет делать даже простые задачи на реальном проекте.

И возвращаясь к автоматизированному тестированию. Да, безусловно у тестировщика занимающегося автоматизацией, очень хорошая фора перед тестировщиком. Тем не менее скрипты по автоматизации на порядок проще, чем реальный код.
Таким образом тестировщик, который занимался автоматизацией имеет уже некий задел в основах программирования и может быть языке. Тем не менее все остальные пункты все еще остаются той базой, которую ему придется выучить до того, как стать программистом, приносящим пользу.

Сегодня хочу дополнить один штрих к той статье, хотя безусловно, она заслуживает продолжения и более детального расписывания.

То, что я видел в нескольким компаниях в штатах, это достаточно странный метод выбирания, что делать. Само собой идеи сыпятся со всех сторон – от заказчиков, от менеджмента, от разработчиков, что в целом нормально.

Вопрос только, заключается в том, что

а) Нету человека или отдела, который отвечает за то, что идет в производство, а что нет. Чаще всего решение происходит полураспределенным путем, то есть где-то что-то замкнулось и выстрелило и новую функциональность поставили на конвеер для выпуска.

б) Нету четкого метода оценки насколько идея “интересна” компании. То есть продукт представляет собой такое, размытое облако и поэтому тяжко сказать, другое размытое облачко сильно соприкасается с ним или нет.

в) Метод выбора идей зачастую базируется на том, кто “громче кричит” (и тем самым привлекает внимание менеджмента).

Возвращаясь к той структуре, которую я нарисовал.
Именно поэтому я считаю, что
а) Должен быть отдел, который занимается сбором всей информации и решением, что идет таки на производство.
б) Этот отдел должен иметь достаточно четкий критерий оценки идей (например, учитывая количество заявок от заказчиков, потенциальные стоимость реализации функциональности, потенциальный размер рынка, нахождение функциональности внутри направления развития продукта).

В этом случае, вполне понятно, кто в конечном счете отвечает за принятие решений и на основе каких параметров они принимаются.

Так что буду потихоньку эту тему раскапывать.

В общем ситуация следующая. Неправильная иерархия для компания, делает тоже самое что неправильная архитектура для программы. То есть при неправильной иерархии вроде и все работать
может, но сбоит по черному и непонятно откуда у проблем растут ноги.

Итак, сначала покажу схемку, которую я набросал пару месяцев назад. Сразу скажу, что могут быть какие-то огрехи, но главное я хотел передать идею….

Итак, вот она схемка. Схемка того, как должна выглядеть продуктовая контора или продуктова/сервисная. Впрочем даже сильно сервисная может так тоже выглядеть, но с небольшими модификациями.

А теперь, о том, что я имел ею в виду

- Первое и самое основное (того, чего в схемке не указано). У каждой позиции должен быть четкий список обязанностей и ответственности. Директор по продажам не должен садиться подпедалить код,
а технический менеджер не должен мотаться по всему миру собирая у заказчиков требования.
Я кстати об этом писал в статье “О разделении обязанностей между технарями и продавцами.”

- Второе. Это размер фирмы. Естественно, нарисованная фирма скорее выглядит как что-то эдак размером человек 500. Скажем так, многие из этих должностей могут быть объедененны в одном человек для небольшой фирмы. Главное, что можно объеденять должности внутри одного подразделения, но не между ними.

То есть может быть и программист и главный программист в одном лице. И product manager с business director’ом в одном лице. Но уж никак не главный QA и sales director в одном флаконе.

Теперь можно уже и по структуре. Основное, с чего я вообще начал рисовать эту схему с Product Manager’а. Звучит конечно смешно, но это самый главный человек в компании. C одной стороны он находится достаточно низко в структуре, чтобы влиять на детали, с другой стороны достаточно высоко, чтобы выбирать направление. В этому его уникальность и ценность одновременно.

Итак, самая основная его идея в том, чтобы собирать все хотелки сверху (от CEO, от Sales (это скорее сбоку)), идеи о том куда двигаться в будущем (от маркетинка), крики и плевки от заказчиков (через отдел support’а) и пинки от engineering’а. После того, как все собрано – все приоритезируется и выдается вниз engineering’у на исполнение и вверх отчетность о приоритетах.

Замечу, дальше в зависимости от удачности или не удачности приоритезации именно product manager’ов (включая business development director) должны либо гладить по голове, либо гладить утюгом.

То есть к ним идут все ниточки входных сигналов и от них идут все ниточки выходных сигналов. Еще раз замечу, не к CEO, а к ним.

Теперь, расходимся от них концентрическими кругами.

В случае если product  manager’ов несколько – то Business Director как раз должен руководить, тем чтобы ниточки по нужным направлениями шли к нужному product manager’у и в ответ выходили нужные ответные сигналы.

Кстати, замечу, что если входные сигналы имеют право быть аналоговыми (то есть в достаточно произвольной форме), то выходные сигналы – все должны быть очень цифровым (четкий формат в виде документа с требованиями для инженеров, документа с планом и сроками для sales и т.п.)

Движемся дальше. Когда сигнал опускается до director’а engineering’а – то он обычно заключается в крупных проектах и это уже его дело разбить это напроекты поменьше, раздать менеджерам проектов х контролировать и т.п. В общем-то director engineering’а и project manager’ы это как раз те самые менеджеры среднего звена о которых я писал уже несколько раз.

Дальше движемся вверх по схеме. CEO по большему счету должен быть нужен в фирме для трех вещей

а) В случае наличия инвесторов – общение с ними

б) В случае если он основатель и задумщик идеи – он должен кормить этими идеям product manager’а. Хотя в идеале, тогда он должны перейти на должность Business Development Director и отдать руль CEO кому-то другому.

в) В случае если какая-то ветка работает плохо, разобраться в причине и уволить ее.

Ну и плюс сюда можно приписать воодушивительные выступления перед фирмой.

По большему счету это все, за что он должен отвечать

To be continued…

P.S. Круто… Первая картинка в блоге

Что я отлично понял, когда был владельцем фирмы – все что может не работать – будет не работать. Даже самая распрекрасная идея имеет тенденцию разваливаться, когда она не находится под контролем.

Поэтому единственный способ, достичь того, чтобы какой-то процесс или система работала – сделать метод, который не позволял бы процессу или системе выключиться. В общем жестокая обратная связь. Как только система начинает отклоняться, то должна возникать сила которая приводит систему обратно в порядок.