Где-то через год, когда, у меня образовалось место, где с одной стороны можно (и хочется) поваляться на диване, а с другой стороны есть интернет, я решил, что пришла пора настроить себе беспроводную сеть. Не помню уж почему я не купил wifi router (может были дорогие, а может просто найти в Харькове не смог). Но, я таки купил пару Bluetooth’ов, один воткнул в стационарный комп, а второй в notebook и настало мне (и моей жене) счастье.

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

Но, это так сказать присказка. Сказка впереди.

Два дня назад я заметил, что когда общаюсь по Skype по работе (сидя у себя дома), то раз в секунд 20 начинает дико рвать. Ну, думаю, опять с инетом проблемы. Покопался-покопался, и обнаружил, что проблемы не с инетом, а с WiFi. Ping до роутера регулярно пропадает. Ну думаю, это дело уже не впервой, наверное кто-нибудь начал использовать тот же канал, что и я. Запустил программку iStumbler и офигел, так как с того места где я сижу, видно с штук 7-8 сетей. Пошел в другую комнату (где собственно стоит WiFi router) и офигел еще больше, так как там видно уже за десяток сетей.

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

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

В общем, махнул рукой, решил купить новый 802.11n router, учитывая то, что вокруг N сетей нет. Взял мощный router – Netgear WNDR4000, в надежде того, что я смогу добиться обещанной скорости 750Mbit/s. Пришел, настроил… все работает, только вот скорости нету.

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

а) Заявленная ими скорость – 750Mbit/s.

Насколько я понимаю это суммарная максимальная скорость на 2.4GHz – 300 Mbit/s + 5.8Gz – 450 Mbit/s.
Может ли один клиент (с одной Wifi карточкой), например обычный notebook использовать два диапазона одновременно и соответственно получить эти полные 750Mbit/?

б) По поводу 450Mbit/s на 5.8GHz

Уж не помню, на каком форуме я читал, что для того, чтобы добраться до этих самых 450MBit/s на 5.8GHz нужна какая-то хитрая карточка, которых пока мало. А большинство notebook’ов максимально могут добраться до 300Mbit/s на 5.8GHz.

в) Из экспериментального.

Я максимально смог добраться до 300MBit/s подключения на 5.8GHz. Находясь в прямой видимости, на расстоянии нескольких метров.

Даальше я начал передавать файл и снова офигел. Я ожила, что скорость будет порядка той самой 300MBit/s. Фигушки вам, реальная скорость оказалась порядка 100MBit/s (кстати о которой тоже читал в разных отзывах).

г) Итого суммируя все вышеперечисленные вопросы

Вообще, реально выжать из этой радости больше чем 100Mbit/s передачи. Если нет, то я думаю буду искать другие варианты, так как цена у роутера откровенно высокая, и при всех этих заявленных 750MBit/s, у меня на руках получается всего 100Mbit/s что совсем не интересно.

Буду благодарен за любую инфу на эту тему.

Раньше у меня компьютер выглядел как новогодняя елка – несколько Visual Stud’ий, GCC, Codewarrior, куча всяких SDK и другой разработческой дребени, куча пользовательских программ. В общем, море разного софта, который во первых добавлял тормоза, во вторых конфликтовал, а в третьих просто запутывал где находится что.

Сейчас, наконец все раскидал по виртуальным машинам. Одна для разработки под Windы c студиями, вторая с Ruby, Oracl’ом, Jboss и прочей Web фигней, еще несколько для разных заморочек (домен, RMS Server, чистая XP для тестирования). Спокойно включаю и гашу их когда нужно.

А на реальной машине пользовательский софт и само собой VMWare.

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

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

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

Да, кстати, чтобы расставить все на свои места. Я не верю, что в 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/базы данных
г) Изучить инструменты для программирования
д) Изучить такие вещи как ООП
е) Пописать программы, чтобы понять, что правильно, а что неправильно

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

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

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

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

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

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

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

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

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

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

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

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

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