Всего за 129 руб. Купить полную версию
Практический совет, как спокойно без нервов избавиться от бестолкового программиста.
Никто не застрахован, и я тоже, получить в команду разработчика не умного, но скандального, от которого могут случиться неприятности. И работа не будет сделана, и клиент скандалит с одной стороны, а с другой стороны разработчик требует денег.
Совет первый: не скрывайте ситуацию от клиента, если есть возможность заменить программиста сделайте это немедленно, не тяните время.
Совет второй: при первых признаках, что программист с «заскоком», блокируйте доступ, меняйте пароли, отстраняйте от работы. Не медлите. Как распознать «заскоки», ну вы ж не вчера, я надеюсь, бизнес открыли. Попросите совета и рекомендацию другого программиста, чтобы он адекватно проанализировал ситуацию, если вы сами не очень, пока что, разбираетесь.
Совет третий: включите сразу другого разработчика, с целью, чтобы убедиться, что код в базах не зашифрован, и необходимые модули присутствуют. Это можно проверить, подняв прошлые бэкапы (архивированные копии баз).
Совет четвертый: если программист начинает требовать от вас деньги за работу, которую он не выполнил в первую неделю возникшего конфликта, не нужно обострять ситуацию до критического момента. Любые споры разгораются всё больше, если в них «подбрасывать дров», первые две недели от момента возникновения инцидента нужно всеми возможными усилиями сглаживать острые углы. С клиентом вы проблему уладите, но вот с разработчиком дело будет сложнее. Он потратил время, и его претензия будет заключаться в шантаже и вымогательстве с целью забрать денег в наглую и по-хамски. В данном случае не пройдёт просто заблокировать номер, это может вызвать неадекватную редакцию (даже не возьмусь предсказывать, что может произойти). Нужно проводить разъяснительную работу, в спокойном тоне, не раздражаясь и не выливая негативные эмоции. Время будет играть на вашу пользу, если вы, подкрепляясь фактами, будете обосновывать ваш отказ оплаты, прежде всего отсутствием результата. Прошу понять, что причина «отсутствие результата» и «ты бестолковый» это две большие разницы. Почему результат не случился, надо проанализировать объективно и сделать совместные выводы. Просто «отморозиться» и «абстрагироваться» от проблем не пройдёт. Спокойно относитесь к угрозам, с посыланием на вашу голову всех проверок, аудитов, и кары небесной. Если бы этот разработчик был действительно такой серьёзный, сидел бы он в рядовых программистах на шабашках? Да нет конечно, уже бы сам своей фирмой руководил, а не пыль в глаза пускал.
Какие выводы можно сделать из этой главы?
Своего родного разработчика оставить, вон в углу в стареньких джинсах сидит копается, или гнать его взашей и нанимать при случае экспертов?
Конечно же вам решать, вам ведь виднее. Вы же своим бизнесом руководите, а не я, вы и думайте головой.
Глава 2. Порассуждаем о размерах, компаний конечно
Подумать только, что из-за какой-то вещи можно так уменьшиться, что превратиться в ничто.
«Алиса в стране чудес» Льюис Кэрролл
Любая из больших компаний это колосс на глиняных ногах. Можете со мной не согласиться, но я вас уверяю, что любой из бизнесов можно разрушить, всего лишь создав информационное поле о его неплатежеспособности, подкреплённой отсутствием своевременных платежей по счетам поставщиков. Пару тройку месяцев и любой гигант завалится, и на обломках ещё долго будут бродить коллекторы, кредиторы и банки подбирая крошки среди дымящихся развалин.
Про банки и истории с коррумпированными банковскими служащими можно писать много, и о том, как бизнес банкротится сознательно с целью не вернуть кредиты, но книга не об этом, поэтому оставим эти рассуждения для следующих изданий.
Чем больше бизнес, тем больше в нём размытости, неопределённости, неуверенности в декларируемой прибыли. Собственники, вырастив компанию до оборотов сотню миллионов долларов в год, могут теперь только ориентироваться на сумму денег, которую они могут выручить в случае продажи бизнеса. Другим показателям, из-за потери контуров операционной деятельности, доверие низкое, по причине отрицания (внутреннего конечно) о том, что такая махина может нести и убытки тоже.
Такие компании просто клондайк для IT сектора. Бюджеты подтверждаются, не без проблем конечно, но всё же в приличных размерах. Обычным делом в таких корпорациях считается назначение при старте проекта одного ответственного, в середине проекта следующего, ну а дальше конца и края конечно действующим лицам не видно. Там смотришь, уже и разработчики сменились, и фамилию первого ответственного в компании никто уже и не вспомнит.
Солдат спит, а служба идёт. Код пишется, все трудятся в поте лица, бюджет осваивается в полном объёме.
Ну а если проект не удался, так кто виноват?
Ну конечно же тот, кто был первым ответственным за проект.
А где он делся?
Уволился, и след его простыл.
Почему уволился?
Так вот в записке перед уходом написал: «Не вижу даты окончания проекта. Прошу в моём увольнении никого не винить».
Компания большая, время идёт, и паровоз мчится дальше, таща за собой вагоны и маленькие тележки ещё таких же проектов в разных областях. Сумму затрат старательная бухгалтерия спишет на убытки, и через год уже никто ничего не вспомнит, всё поросло забвением и мхом.
Нет, конечно же автор не хочет сказать, что это происходит во всех компаниях. Где-то конечно результат, какой-никакой получается. Пусть плохонький, на костыликах, но он есть.
Сложно измерить процент не сложившихся проектов на бизнес просторах за последние 30 лет независимости страны, да и кто же нам в этом сознается. Расписаться в неудачах, сложно, гораздо проще задекларировать успехи.
Если прикинуть навскидку, по статистике: из 100% IT стартапов 99% прогорает, а 1% выживает.
Сколько из 1% выживет ещё через 5 лет? В такой же пропорции.
Исходя из этой логики, такой же и процент выполнения IT проектов в компаниях.
И опять же, а что можно считать результатом? Это вам знаете ли не свитер связать из бабушкиной пряжи, где объект более-менее понятен в своём масштабе, да и материал ощутим в своём качестве и количестве.
В больших компаниях есть определённая стратегия, которую используют недальновидные менеджеры, цель которых как можно больше выслужиться перед начальством.
А как это сделать если особыми навыками и компетенциями не обладаешь?
Всё очень просто.
Для начала инициируется IT проект, более-менее приличных масштабов, чтобы в нем было задействовано как минимум пару тройку отделов компании, не считая самих разработчиков. Определяются контуры, и предварительные зарисовки, что нужно получить по итогу автоматизации. Далее, эти самые ушлые менеджеры, которые несомненно вызовутся руководить данным проектом, начинают приглашать представителей сторонних IT компаний, и предлагать им осуществить нарисованное на бумаге в жизнь. Начинается бурная деятельность: дискуссии, встречи, чаепитие, кофее питие, печеньки дешёвенькие, вопросы, ответы, предложения, согласование бюджета. И так шаг за шагом вырисовывается план проекта, который становится более-менее понятен, потому, что в его разработке приняли участие IT компании, обладающие компетенцией в поставленной задаче. Финалом таких встреч является отправка со стороны потенциального исполнителя (читайте: «жертва обмана») коммерческого предложения со стоимостью данной разработки.
Что происходит дальше для IT компании, потенциального подрядчика?