Практический совет, как спокойно без нервов избавиться от бестолкового программиста.
Никто не застрахован, и я тоже, получить в команду разработчика не умного, но скандального, от которого могут случиться неприятности. И работа не будет сделана, и клиент скандалит с одной стороны, а с другой стороны разработчик требует денег.
Совет первый: не скрывайте ситуацию от клиента, если есть возможность заменить программиста сделайте это немедленно, не тяните время.
Совет второй: при первых признаках, что программист с «заскоком», блокируйте доступ, меняйте пароли, отстраняйте от работы. Не медлите. Как распознать «заскоки», ну вы ж не вчера, я надеюсь, бизнес открыли. Попросите совета и рекомендацию другого программиста, чтобы он адекватно проанализировал ситуацию, если вы сами не очень, пока что, разбираетесь.
Совет третий: включите сразу другого разработчика, с целью, чтобы убедиться, что код в базах не зашифрован, и необходимые модули присутствуют. Это можно проверить, подняв прошлые бэкапы (архивированные копии баз).
Совет четвертый: если программист начинает требовать от вас деньги за работу, которую он не выполнил в первую неделю возникшего конфликта, не нужно обострять ситуацию до критического момента. Любые споры разгораются всё больше, если в них «подбрасывать дров», первые две недели от момента возникновения инцидента нужно всеми возможными усилиями сглаживать острые углы. С клиентом вы проблему уладите, но вот с разработчиком дело будет сложнее. Он потратил время, и его претензия будет заключаться в шантаже и вымогательстве с целью забрать денег в наглую и по-хамски. В данном случае не пройдёт просто заблокировать номер, это может вызвать неадекватную редакцию (даже не возьмусь предсказывать, что может произойти). Нужно проводить разъяснительную работу, в спокойном тоне, не раздражаясь и не выливая негативные эмоции. Время будет играть на вашу пользу, если вы, подкрепляясь фактами, будете обосновывать ваш отказ оплаты, прежде всего отсутствием результата. Прошу понять, что причина «отсутствие результата» и «ты бестолковый» это две большие разницы. Почему результат не случился, надо проанализировать объективно и сделать совместные выводы. Просто «отморозиться» и «абстрагироваться» от проблем не пройдёт. Спокойно относитесь к угрозам, с посыланием на вашу голову всех проверок, аудитов, и кары небесной. Если бы этот разработчик был действительно такой серьёзный, сидел бы он в рядовых программистах на шабашках? Да нет конечно, уже бы сам своей фирмой руководил, а не пыль в глаза пускал.
Какие выводы можно сделать из этой главы?
Своего родного разработчика оставить, вон в углу в стареньких джинсах сидит копается, или гнать его взашей и нанимать при случае экспертов?
Конечно же вам решать, вам ведь виднее. Вы же своим бизнесом руководите, а не я, вы и думайте головой.
Глава 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 час, улетает в расходы и бьёт по карману этого собственника, так, что приходится искать на чём в этом месяце сэкономить, чтобы программисту заплатить.
Большие IT компании не хотят связываться с таким бизнесом не только потому, что бюджет скромный, а потому, что аппетиты получения за эти средства у заказчика ого-го какие большие.
У маленьких компаний способ выживания в большом мире бизнеса достаточно простой: «выжми по максимуму, отожми по полной». По-другому компания не выживет, она не может позволить себе разбрасываться налево направо своими оборотными активами, затопчут конкуренты.
У собственников амбиции не маленькие, рано или поздно хороший проект себя покажет и вырастет, но на этапе выпрыгивания из штанишек, которые становятся малы и хочется большего, иметь дела с такими предпринимателями дело весьма, как бы так поделикатнее сказать, «тонкое» и для нервов затратное.
Переговорный процесс в ходе обсуждения программных работ сразу упирается в вопрос:
«А сколько это будет стоить?»
Цена, если она выше 100 условных единиц, всегда будет считаться априори «дорого» и подкрепится аргументом, что вот мол у таких-то «каких-то разработчиков» всё гораздо дешевле.
Ребята, но это же вам не китайские трусы на базаре выбирать. Вопрос качества явно не ощутим и его не разглядеть в микроскоп. И, очень важный момент, когда кто-то из программистов уже начинает работать с компанией, то его стоимость будет уже в разы ниже, из-за осведомлённости и ориентированности в базе данных.
Даже сторговавшись по сумме и приступив к работе, надо быть готовым, что без детально проработанного технического задания (так как его никто писать не собирался), IT компанию начнут выжимать как лимон, до последней капли сока.
Попытки отбрыкаться, увещевать, аргументировать, пусть даже явными и очевидными фактами, не помогут.
Собственник навалится на вас всем своим телом и будет требовать всё больше и больше, положа на стол свой козырный джокер: «НУ ВЫ ЖЕ ОБЕЩАЛИ, ЧТО ВСЁ БУДЕТ РАБОТАТЬ».
Что «всё» не уточняется.
Всё это значит ВСЁ, и точка, точнее две точки над буквой «ё».
Прокрутив киноленту назад до той самой точки и злополучной даты, когда вы договаривались о реализации технического задания, вспоминаем каверзный вопрос: «А оно будет всё работать», что вы ответили?
Ну конечно «да». Было бы странно, если бы вы ответили «нет».