Как программисты налево ходили. Бизнес-советы предпринимателям

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

Я с подобными компаниями на практике сталкивалась (обойдёмся без имён и названий, тем более, что часть из них уже канули в лету), и конечно же попала в ловушку доверия, но сделав выводы, пришла к правильному решению:

«Ни ногой к разработке технического задания, до тех пор, пока не будет понятно, кто за него заплатит». А платить за техническое задание на практике 99% таких вот хитрых компаний, абсолютно не готово. И уж поверьте, тот кто оплатит, тот на 100% эту работу закажет, так как понимает, что это обоюдовыгодный интерес.

Поэтому, или приступаем к работе при понимании грубых контуров и ожидаемого результата, при подписанном договоре, или делаем техническое задание, за которое получаем ПРЕДОПЛАТУ.

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

САМЫМ ЛУЧШИМ ПОДТВЕРЖДЕНИЕ ДРУЖЕСКОГО ОТНОШЕНИЯ И ДОВЕРИЯ СО СТОРОНЫ КЛИЕНТА, ЯВЛЯЕТСЯ ПРЕДОПЛАТА НА РАСЧЁТНОМ СЧЕТУ.

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

Господа, а вы, когда сотрудника на работу берёте, и он там что-то месяц ковыряется, но вы ж ему зарплату по законодательству заплатите?

Так вот и представитель IT компании бесплатно ничего делать не будет.

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

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

Очень часто многие специалисты считают, что проработанное техническое задание – это как проект строящегося здания.

Соглашусь на 100%.

Но есть одно «Но».

Вы в курсе сколько стоит хороший проект? Поверьте – очень дорого.

И надо понимать, что:

во-первых, хорошее крепкое здание простоит 100 лет, а автоматизированный процесс прослужит в лучшем случает лет 15;

во-вторых, у строящегося здания, вырисованного на картинке, есть контуры, фасад, и как минимум понимание заказчика, как оно должно выглядеть по итогу;

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

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

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

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

Если проект не удался, ну что ж, спишут безнадёжную инвестицию с баланса компании и забудут, как плохой сон.

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

Маленькая компания для серьёзной IT компании никакого интереса не представляет.

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

А что может себе позволить собственник компании с ежемесячным оборотом в 30 000 долларов?

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

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

У маленьких компаний способ выживания в большом мире бизнеса достаточно простой: «выжми по максимуму, отожми по полной». По-другому компания не выживет, она не может позволить себе разбрасываться налево направо своими оборотными активами, затопчут конкуренты.

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

Переговорный процесс в ходе обсуждения программных работ сразу упирается в вопрос:

«А сколько это будет стоить?»

Цена, если она выше 100 условных единиц, всегда будет считаться априори «дорого» и подкрепится аргументом, что вот мол у таких-то «каких-то разработчиков» всё гораздо дешевле.

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

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

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

Собственник навалится на вас всем своим телом и будет требовать всё больше и больше, положа на стол свой козырный джокер: «НУ ВЫ ЖЕ ОБЕЩАЛИ, ЧТО ВСЁ БУДЕТ РАБОТАТЬ».

Что «всё» – не уточняется.

Всё – это значит ВСЁ, и точка, точнее две точки над буквой «ё».

Прокрутив киноленту назад до той самой точки и злополучной даты, когда вы договаривались о реализации технического задания, вспоминаем каверзный вопрос: «А оно будет всё работать», что вы ответили?

Ну конечно «да». Было бы странно, если бы вы ответили «нет».

Потому, что ваше понимание «всё» имело чёткие рамки и границы, которых у противоположной стороны явно не было, и контуры были размыты. А раз чётких очертаний границ дозволенного не нарисовано, то извольте батенька делать, пахать с утра до ночи.

Конечно, зайдя в тупик, и находясь в положении нависшей угрозы неоплаты того минимума на который компания согласилась (а теперь вы начинаете понимать, что законные требования на 50% предоплаты явно обоснованы), программисты ещё конечно попрыгают для достижения того самого эфемерного «всё и сразу», но эти прыжки к окончательному результату не приведут, так как включится ещё один фактор, название которого:

«сотрудники небольшой компании заказчика».

Если вы спросите меня есть ли разница между сотрудниками больших, средних, и маленьких компаний?

Есть, да и ещё какая.

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

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

Порассуждаем о размерах самих IT компаний и как это влияет на выполняемые работы.

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

Почему к сожалению?

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

Творческие люди – это тело на 99,9%, заряженное эмоцией, в то время как разработчик вдоль и поперёк заряжен прагматизмом, на эмоции его не прошибёшь. Вот именно поэтому попытка доказать, например, что Бог есть, никак не укладывается в логику алгоритмических уравнений, которыми сплошь напичкана голова разработчика. Конечно, проще думать, что человек произошёл от обезьяны, и ведом по жизни базовыми инстинктами. Именно поэтому закон сохранения энергии так важен в IT сфере, в противном случае эмоциональное выгорание не за горами.

– Серьёзное отношение к чему бы то ни было в этом мире является роковой ошибкой.

– А жизнь – это серьёзно?

– О да, жизнь – это серьёзно! Но не очень…

«Алиса в стране чудес» Льюис Кэрролл

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

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

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

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

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

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

«Нужно бежать со всех ног, чтобы только оставаться на месте, а, чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!»

«Алиса в стране чудес» Льюис Кэрролл

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

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

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

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

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

Представили?

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

Понимаете, что по-разному. А ещё им надо договориться о синергии и эффективной коммуникации.

Тяжело это будет, и в жизни практически не реализуемо.

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

Глава 3. Программисты не вечны, и вы тоже.

«Если бы каждый человек занимался своим делом, Земля бы вертелась быстрее».

«Алиса в стране чудес» Льюис Кэрролл

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

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

Знаешь, одна из самых серьезных потерь в битве – это потеря головы.

«Алиса в стране чудес» Льюис Кэрролл

Однозначно, что тысячи компаний провалили тысячи проектов просто по причине того, что не провели предварительное исследование, Research.

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

Research – подразумевает сбор информации по всем вопросам проекта, в т.ч. информацию о рынке конкретного продукта.

Задача такого исследования – анализ внутренней и внешней среды предприятия и подготовка на этой основе информации, необходимой для принятия решений, касающихся нового проекта

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

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

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

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

Алиса в стране чудес Льюис Кэрролл

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

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

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

ЗАПОМНИТЕ, ЧТО В 99,9999999% СРОКИ IT ПРОЕКТОВ НЕ ВЫПОЛНЯЮТСЯ, И ПЕРЕДВИГАЮТСЯ НА БОЛЕЕ ПОЗДНИЕ ДАТЫ!

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

ВАЖНО ПОМНИТЬ, ЧТО В ТАКОЙ СИТУАЦИИ КОД НА СЛЕДУЮЩЕЕ УТРО НЕ ЗАРАБОТАЕТ.

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

Советы СТОРОНЕ, предоставляющей услуги программистов.

Совет 1. Когда называете сроки выполнения клиенту смело прибавляйте ровно половину к сроку, указанному программистом. В противном случае вас ожидает нескончаемая череда дней, под названием «завтра всё будет готово», именно так вы будете отвечать каждый день клиенту, который будет вам звонить с вопросом, о том, когда будет закончена работа.

Завтра никогда не бывает сегодня! Разве можно проснуться поутру и сказать: «Ну вот, сейчас наконец завтра»?

«Алиса в стране чудес» Льюис Кэрролл

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.