Теперь, помыслив логически, мы приходим к выводу, что, если программистами будет руководить человек, который имеет базовые знания написания кода, и может даже сам что-то написать умненькое, по факту, в проекты вникать не будет. Разбираться в задачах, которые ставят операционные менеджеры разработчикам остаётся в зоне влияния самих же разработчиков.
Представим себе такую картину, что в какой-то комнате в полной изоляции сидят несколько людей, чем они там занимаются, конечно, никто особо не разбирается, так как допуск в комнату посторонним запрещён. Через маленькое окошко в эту самую комнату подаются написанные задания, и оттуда через какое-то время (через какое никому точно неизвестно, сроки передвигаются, задач много, нервов на всех не хватает) выдаётся некий результат.
В момент возмущения выданными данными, приходит ответ, возможный вариант ответа на листике бумаги от руки написанный, следующий:
«Устраивает, не устраивает, а что вы хотели, как написали в письме, так и сделали. Написано же «семь зелёных клеток с точками, вот и получите. Что? Хотели точки над зелёными клетками и клетки в один ряд, а не на друг друге? Ну извините, мы тут заняты, нам тут домысливать некогда. Пишите задачу на доработку».
И вот теперь вы только начинаете понимать и потихоньку догонять, что на самом деле в отделе программистов происходит.
Думаете они там в компании сидят, работают, что аж дым из ушей валит, вон гляди всё кофе опять выпили.
Открою вам небольшой секрет, вам знакомо выражение: «солдат спит, а служба идёт»?
Так вот и у программистов, которые устраиваются в штаты компаний, чтобы иметь базовый оклад, запись в трудовой книжке (а то как-то 18 лет фрилансера, в резюме не очень смотрится), и спокойно себе искать проекты на стороне, то же самое.
Я очень долго смеялась, когда один дядечка с очень большой компании рассказывал о таких методах работы контроля программистов, как ежечасно делать снимок рабочего экрана, чтобы понимать, что бедолага сейчас делает и чем занят. Ну фотографируйте экран, а этот самый товарищ всю ночь не спал, проект на стороне «пилил», сидит пятую кружку кофе пьёт и в абсолютно не ресурсном состоянии.
Ну а что?
Он думает так: «мышкой» по экрану повожу, что-то напишу, потом опять перепишу, потом скрипт обновлю, потом на отладку поставлю, и опять по кругу. Там глядишь и день прошёл, и зарплата скоро. Сиди себе кофе прихлёбывай, да сахарку побольше ложи. А кто померяет сколько наработал? Вон глядишь начальник мой, тоже к машине побежал, там у него ноутбук личный запрятан, что-то срочно решить другому клиенту надо. Клиентами делится, не жадничает, только с часа процент отдавай. Так что город засыпает, а мафия просыпается. И наоборот.
Наверное думаете, что я выдумываю, и это только некоторые недобросовестные разработчики так делают.
А вы посидите и подумайте, только очень хорошо, логически выстройте цепочку.
В большинстве своём разработчики – это мужчины. Устройство в компанию сродни определённому брачному контракту, в котором базовые обязательства соблюдены, а вот в свободное время, это ещё надо подумать кто кому и что должен.
Каждый день одно и тоже, разнообразием не пахнет, одна и та же компания, одни и те же надоевшие лица, по типу с претензиями «опять программа не работает, потому что шнур уборщица задела, или того хуже проливающие чаи и кофе на клавиатуры, но при этом утверждающие что ничего подобного в их жизни никогда не случалось.
Скучно, батенька, скучно тут с вами. А вот там на стороне – ОПЫТ, ГОСПОДА. Разнообразие, за которое, между прочим, ещё и деньги предлагают, и что самое важное даже похвалить могут, а не дармоедом обзывают, и в отпуск только в феврале и ноябре отпускают, когда все остальные летом и на новогодние праздники, из которых только к середине мая возвращаются.
Поэтому, извините конечно, но свобода движений, новые контакты, новые вызовы ни в какое сравнение с вашей серой будничной унылой жизнью даже рядом не стояли. Поэтому летят программисты к новому и неизвестному. А на работе что, могу и с открытыми глазами поспать пока компьютер перезагружается. А вы попробуйте словить на бездействии, да ничего у вас не получится, это вам не яму копать, и не болванку на станке клепать, по норме 2 болванки без брака в час. В 1С таких болванок не настрогаешь, тут знаете индивидуальный творческий подход нужен.
Рассказов про то, почему так долго делали задачу, я в своё время наслушалась очень много, и до сих пор выслушиваю сердобольные истории.
На элементарный вопрос, почему отчёт, который можно за 8 часов собрать, а не три недели ждать мне ответили таким образом: «А вы знаете сколько мне над этим пришлось думать?»
Знаю батенька, знаю, не фига ты не думал, дурака валял, и другими делами занимался, поэтому иди-ка ты подобру-поздорову, к другим олухам, кто в твои сказки для Панаски поверит. Я в детективные истории про «долго думать» не верю никак, потому, что тому разработчику, которому действительно нужно задачу решить, он и посоветуется и техническое решение выдаст как можно быстрее. И всё потому, что он хочет и задачу закрыть, и денег получить, именно это его и вдохновляет. А прохиндеев на рынке хватает, не успеваешь избавляться, как вон уже новый на горизонте.
Практический совет, как спокойно без нервов избавиться от бестолкового программиста.
Никто не застрахован, и я тоже, получить в команду разработчика не умного, но скандального, от которого могут случиться неприятности. И работа не будет сделана, и клиент скандалит с одной стороны, а с другой стороны разработчик требует денег.
Совет первый: не скрывайте ситуацию от клиента, если есть возможность заменить программиста сделайте это немедленно, не тяните время.
Совет второй: при первых признаках, что программист с «заскоком», блокируйте доступ, меняйте пароли, отстраняйте от работы. Не медлите. Как распознать «заскоки», ну вы ж не вчера, я надеюсь, бизнес открыли. Попросите совета и рекомендацию другого программиста, чтобы он адекватно проанализировал ситуацию, если вы сами не очень, пока что, разбираетесь.
Совет третий: включите сразу другого разработчика, с целью, чтобы убедиться, что код в базах не зашифрован, и необходимые модули присутствуют. Это можно проверить, подняв прошлые бэкапы (архивированные копии баз).
Совет четвертый: если программист начинает требовать от вас деньги за работу, которую он не выполнил в первую неделю возникшего конфликта, не нужно обострять ситуацию до критического момента. Любые споры разгораются всё больше, если в них «подбрасывать дров», первые две недели от момента возникновения инцидента нужно всеми возможными усилиями сглаживать острые углы. С клиентом вы проблему уладите, но вот с разработчиком дело будет сложнее. Он потратил время, и его претензия будет заключаться в шантаже и вымогательстве с целью забрать денег в наглую и по-хамски. В данном случае не пройдёт просто заблокировать номер, это может вызвать неадекватную редакцию (даже не возьмусь предсказывать, что может произойти). Нужно проводить разъяснительную работу, в спокойном тоне, не раздражаясь и не выливая негативные эмоции. Время будет играть на вашу пользу, если вы, подкрепляясь фактами, будете обосновывать ваш отказ оплаты, прежде всего отсутствием результата. Прошу понять, что причина «отсутствие результата» и «ты бестолковый» – это две большие разницы. Почему результат не случился, надо проанализировать объективно и сделать совместные выводы. Просто «отморозиться» и «абстрагироваться» от проблем не пройдёт. Спокойно относитесь к угрозам, с посыланием на вашу голову всех проверок, аудитов, и кары небесной. Если бы этот разработчик был действительно такой серьёзный, сидел бы он в рядовых программистах на шабашках? Да нет конечно, уже бы сам своей фирмой руководил, а не пыль в глаза пускал.
Какие выводы можно сделать из этой главы?
Своего родного разработчика оставить, вон в углу в стареньких джинсах сидит копается, или гнать его взашей и нанимать при случае экспертов?
Конечно же вам решать, вам ведь виднее. Вы же своим бизнесом руководите, а не я, вы и думайте головой.
Глава 2. Порассуждаем о размерах, компаний конечно
Подумать только, что из-за какой-то вещи можно так уменьшиться, что превратиться в ничто.
«Алиса в стране чудес» Льюис Кэрролл
Любая из больших компаний – это колосс на глиняных ногах. Можете со мной не согласиться, но я вас уверяю, что любой из бизнесов можно разрушить, всего лишь создав информационное поле о его неплатежеспособности, подкреплённой отсутствием своевременных платежей по счетам поставщиков. Пару тройку месяцев и любой гигант завалится, и на обломках ещё долго будут бродить коллекторы, кредиторы и банки подбирая крошки среди дымящихся развалин.
Про банки и истории с коррумпированными банковскими служащими можно писать много, и о том, как бизнес банкротится сознательно с целью не вернуть кредиты, но книга не об этом, поэтому оставим эти рассуждения для следующих изданий.
Чем больше бизнес, тем больше в нём размытости, неопределённости, неуверенности в декларируемой прибыли. Собственники, вырастив компанию до оборотов сотню миллионов долларов в год, могут теперь только ориентироваться на сумму денег, которую они могут выручить в случае продажи бизнеса. Другим показателям, из-за потери контуров операционной деятельности, доверие низкое, по причине отрицания (внутреннего конечно) о том, что такая махина может нести и убытки тоже.
Такие компании просто клондайк для IT сектора. Бюджеты подтверждаются, не без проблем конечно, но всё же в приличных размерах. Обычным делом в таких корпорациях считается назначение при старте проекта одного ответственного, в середине проекта – следующего, ну а дальше конца и края конечно действующим лицам не видно. Там смотришь, уже и разработчики сменились, и фамилию первого ответственного в компании никто уже и не вспомнит.
Солдат спит, а служба идёт. Код пишется, все трудятся в поте лица, бюджет осваивается в полном объёме.
Ну а если проект не удался, так кто виноват?
Ну конечно же тот, кто был первым ответственным за проект.
А где он делся?
Уволился, и след его простыл.
Почему уволился?
Так вот в записке перед уходом написал: «Не вижу даты окончания проекта. Прошу в моём увольнении никого не винить».
Компания большая, время идёт, и паровоз мчится дальше, таща за собой вагоны и маленькие тележки ещё таких же проектов в разных областях. Сумму затрат старательная бухгалтерия спишет на убытки, и через год уже никто ничего не вспомнит, всё поросло забвением и мхом.
Нет, конечно же автор не хочет сказать, что это происходит во всех компаниях. Где-то конечно результат, какой-никакой получается. Пусть плохонький, на костыликах, но он есть.
Сложно измерить процент не сложившихся проектов на бизнес просторах за последние 30 лет независимости страны, да и кто же нам в этом сознается. Расписаться в неудачах, сложно, гораздо проще задекларировать успехи.
Если прикинуть навскидку, по статистике: из 100% IT стартапов – 99% прогорает, а 1% выживает.
Сколько из 1% выживет ещё через 5 лет? В такой же пропорции.
Исходя из этой логики, такой же и процент выполнения IT проектов в компаниях.
И опять же, а что можно считать результатом? Это вам знаете ли не свитер связать из бабушкиной пряжи, где объект более-менее понятен в своём масштабе, да и материал ощутим в своём качестве и количестве.
В больших компаниях есть определённая стратегия, которую используют недальновидные менеджеры, цель которых как можно больше выслужиться перед начальством.
А как это сделать если особыми навыками и компетенциями не обладаешь?
Всё очень просто.
Для начала инициируется IT проект, более-менее приличных масштабов, чтобы в нем было задействовано как минимум пару тройку отделов компании, не считая самих разработчиков. Определяются контуры, и предварительные зарисовки, что нужно получить по итогу автоматизации. Далее, эти самые ушлые менеджеры, которые несомненно вызовутся руководить данным проектом, начинают приглашать представителей сторонних IT компаний, и предлагать им осуществить нарисованное на бумаге в жизнь. Начинается бурная деятельность: дискуссии, встречи, чаепитие, кофее питие, печеньки дешёвенькие, вопросы, ответы, предложения, согласование бюджета. И так шаг за шагом вырисовывается план проекта, который становится более-менее понятен, потому, что в его разработке приняли участие IT компании, обладающие компетенцией в поставленной задаче. Финалом таких встреч является отправка со стороны потенциального исполнителя (читайте: «жертва обмана») коммерческого предложения со стоимостью данной разработки.
Что происходит дальше для IT компании, потенциального подрядчика?
Наверное, вы уже догадались.
ТИШИНА и МОЛЧАНИЕ.
На попытки добиться ответа, шаблон письма от менеджера всегда наготове:
«На согласовании у руководства».
Такое согласование не закончится никогда.
Почему?
Да потому, что в это время, наш герой (тот самый менеджер, про инвестировавший в дешёвые кондитерские изделия для встреч), побеседовав со своими штатными разработчиками, рисует свои цифры бюджета, которые будут сделаны сотрудниками компании, включая премиальный фонд (за экономию).
И вот всё это «детище», в виде презентации, торжественно несётся на несомненно важное совещание (других в больших компаниях не бывает), на котором показывают две картинки затрат: своими силами и чужими руками.
Вот вы лично, например, если пойдёте в магазин и увидите там две бутылки шампуня внешним видом ничем не отличающиеся, но разницей в цене 30% (учтите факт, что вы этим шампунем не будете лично пользоваться), какой выберете?
Правильный ответ: тот, от которого денег на вашей платёжной карте останется больше.
Тем более если ваш менеджер компании, всё изучил, тридцать ночей не спал, продумал всё до мелочей (то, что касается личного вознаграждения, а не проекта, если вы так подумали).
Всё! Проект утверждён, побежали выполнять.
То, что результат будет вдвое хуже, это уже по итогу никого не волнует.
Это как результат операции хирурга: уже никто не сможет сравнить качество выполненной работы, кроме другого квалифицированного специалиста, так как больной думает, что как сделали, так и должно быть.
Я с подобными компаниями на практике сталкивалась (обойдёмся без имён и названий, тем более, что часть из них уже канули в лету), и конечно же попала в ловушку доверия, но сделав выводы, пришла к правильному решению:
«Ни ногой к разработке технического задания, до тех пор, пока не будет понятно, кто за него заплатит». А платить за техническое задание на практике 99% таких вот хитрых компаний, абсолютно не готово. И уж поверьте, тот кто оплатит, тот на 100% эту работу закажет, так как понимает, что это обоюдовыгодный интерес.
Поэтому, или приступаем к работе при понимании грубых контуров и ожидаемого результата, при подписанном договоре, или делаем техническое задание, за которое получаем ПРЕДОПЛАТУ.
Никак по-другому. Ни коим образом не соглашайтесь, что-либо разрабатывать новым клиентам, с которыми не закрепились бизнес-отношения.
САМЫМ ЛУЧШИМ ПОДТВЕРЖДЕНИЕ ДРУЖЕСКОГО ОТНОШЕНИЯ И ДОВЕРИЯ СО СТОРОНЫ КЛИЕНТА, ЯВЛЯЕТСЯ ПРЕДОПЛАТА НА РАСЧЁТНОМ СЧЕТУ.
Сколько угодно можете бросать в меня помидоры и тапки, что мол результат не понятен, а деньги потрачены.
Господа, а вы, когда сотрудника на работу берёте, и он там что-то месяц ковыряется, но вы ж ему зарплату по законодательству заплатите?
Так вот и представитель IT компании бесплатно ничего делать не будет.
Если задаться вопросом, сколько заплатить за разработку технического задания?
Ориентировочно не меньше 10% стоимости будущей выполняемой работы в первой грубой прикидке бюджета.
Очень часто многие специалисты считают, что проработанное техническое задание – это как проект строящегося здания.
Соглашусь на 100%.
Но есть одно «Но».
Вы в курсе сколько стоит хороший проект? Поверьте – очень дорого.
И надо понимать, что:
во-первых, хорошее крепкое здание простоит 100 лет, а автоматизированный процесс прослужит в лучшем случает лет 15;
во-вторых, у строящегося здания, вырисованного на картинке, есть контуры, фасад, и как минимум понимание заказчика, как оно должно выглядеть по итогу;
в-третьих, при визуальном изображении, любой человек, ориентируясь на своё понимание вкуса и цвета, легче понимает где и что улучшить, или поправить.
Это далеко не все перечисленные преимущества. Самое главное нужно усвоить, что отношение к строительству недвижимого имущества несомненно гораздо серьёзнее, хотя бы просто потому, что неправильно спроектированное строение может причинить ущерб для жизни и здоровья людей.
К IT проектам такого отношения нет, и там, где автоматизация несёт за собой высвобождение роли человека, как например автопилот, то такие проекты тянутся очень долго, с большим количеством испытаний и с очень огромными бюджетами.
Большие корпорации могут позволить себе потратить больше, просто хотя бы потому, что и желание получить от этого как минимум существенную экономию, и заработать больше, влечёт за собой приличные инвестиции.
Если проект не удался, ну что ж, спишут безнадёжную инвестицию с баланса компании и забудут, как плохой сон.
С небольшими компаниями дела посложнее, из-за скромного бюджета, прямого согласования собственника, ограниченности проекта.
Маленькая компания для серьёзной IT компании никакого интереса не представляет.
Помню как-то на одной из встреч сокурсников университета «BIG MONEY», один из представителей компании, заявившей о полторы тысячи программистов в штате, сообщил, что на проекты стоимостью меньше чем пятьдесят тысяч долларов они даже и не посмотрят.
А что может себе позволить собственник компании с ежемесячным оборотом в 30 000 долларов?
Конечно же мизер, который при стоимости разработчика начиная от 15 у.е. за 1 час, улетает в расходы и бьёт по карману этого собственника, так, что приходится искать на чём в этом месяце сэкономить, чтобы программисту заплатить.
