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

Поехали!

Часть 4 (продолжение). Проекты

Я продублирую четыре пункта из первой статьи, чтобы не потерять целостность.

1. Выберите нишу.

Многие небольшие компании и отдельные фрилансеры грешат тем, что они занимаются всем. С моей точки зрения – это тупиковый путь развития. Так как заниматься всем невозможно. Вы не сможете конкурировать с нишевой компанией или отдельным разработчиком, если вы занимаетесь всем. Невозможно сесть на 5 стульев одновременно.
Из моего опыта: Как я писал выше, моя основная специализация – это распознавание. До выбора ниши я занимался всем. Но это не очень хорошо получалось, так как мне приходилось в новом проекте изучать технологии, инструменты и аспекты данной задачи. По сути, выбор ниши у меня произошел случайно, после написания дипломной работы. А она была на тему «Распознавание текста с использованием нейронных сетей Хопфилда и Хэмминга». После этого я стал использовать свою библиотеку в проектах. Я стал чаще брать проекты, связанные с распознаванием. А впоследствии сконцентрировался только на них. Естественно я работаю над проектами, в которых распознавание – это лишь малая часть. Но все же. Я оттачиваю свое мастерство от проекта к проекту, а так как это бизнес – я использую свои наработки в новых проектах, чем значительно сокращаю время разработки и получаю бОльшую прибыль за меньший срок.

2. Простота.

Упрощайте все по максимуму. Начиная от интерфейса заканчивая архитектурой. Никому не нужно, чтобы все было запутано. Чем проще – тем лучше.
Из моего опыта: самым лучшим проектом в плане интерфейса, юзабилити и архитектуры, я считаю проект, который был разработан для испанского клиента, о нем я писал выше. Я потратил две недели на разработку архитектуры, но ни сколько не жалею об этом. Так как я до сих пор использую этот движок в других проектах и иногда я просто продаю его. И та простота, которую я заложил в самом начале, она помогла мне адаптировать движок под мои нужды в самые кратчайшие сроки. Хотя испанский проект был очень сложным.

3. От большего к меньшему.

При проектировании более или менее крупного проекта, не пытайтесь охватить все. Это бесполезно! Вы не сможете учесть все нюансы. Сконцентрируйтесь над основными частями системы. Опишите главные моменты и задачи. И приступайте к разработке. Такой подход сравним с подходом скульпторов. Из глыбы они сначала формируют примерный силуэт, а потом, двигаясь от одной части к другой, делают силуэт уже более схожим с реальным объектом. И только в конце они детализируют свою скульптуру. Так должно быть и у Вас. Сделайте большие части программы, а потом разбивайте и дорабатывайте их, делайте более схожими с реальностью.
Из моего опыта: Когда я приступаю к разработке нового проекта, сначала я разделяю его на несколько логических частей. После чего приступаю к разработке. Во время разработки я делю эти логические части на более мелкие и внедряю их. И повторяю это на каждом этапе, делая части более мелкими. Этапы я повторяю до неделимого состояния этих частей.

4. Модульность и масштабируемость.

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

5. Сроки.

Одним из трех самых важных критериев в ИТ-проектах является время разработки проекта. На мой взгляд это самый важный критерий. Так как поговорка «время — деньги» никуда не ушла. И действительно время разработки будет одним из тех самых факторов, которые будут давить на Вас и Вашу команду.
Иногда попадаются очень неадекватные клиенты, но с очень интересными проектами. Вроде бы и ценник устраивает, и проект интересен, но сроки нереальные. Как поступать в данном случае.
Во-первых, сядьте и посчитайте реальное время, которое вам понадобится на проектирование и разработку. После этого умножьте эту цифру на 3. Почему на три? Так получилось, что эта цифра выведена на практике. Объясню: одна треть – идет на разработку, еще одна треть на тестирование и баг-фиксинг, и еще одна треть необходима для интеграции на стороне клиента. Вы можете сказать, что эта цифра нереальна, но для меня очень даже. После того как я начал пользоваться такими расчетами, у меня не было ни одного провального по времени проекта.
Из моего опыта: я всегда говорю клиентам реальную цифру, подчеркну – всегда. Так как бессмысленно врать о цифрах, потому что ложь и недомолвки приведут к срыву сроков. Это закон! Если проект требует к примеру 100 часов. То за 50 его не выполнить никогда. В одном из проектов, я посчитал трудозатраты и огласил их клиенту. На сколько я помню я поставил цифру в 1.5 месяца на фултайме. Он был в шоке. И говорил ASAP чаще, чем можно было придумать. Потом он сказал, что у него есть другая команда, которая предложила ему разработать этот же проект за 3 недели. Я конечно же не поверил, так как эта цифра вообще нереальная для того проекта. И я сказал ему об этом, но он даже не захотел меня слушать. И мы попрощались. И я благополучно забыл про проект, но через месяца 4 этот клиент написал мне письмо, в котором он сказал, что я был прав. За 4 месяца другая команда не смогла даже демо-версию предоставить. Проект, к слову, был точно по моему профилю, а та команда явно не была в теме. Вот почему они и сорвали сроки.

6. Два из трех.

Мой экс бизнес-партнер научил меня этому правилу.
В пятом пункте я упоминал про три самых важных критерия в бизнесе, но я не сказал, что за они. Итак: 1. быстро, 2. качественно, 3.дешево. Если на вас давит клиент, по одному или по всем пунктам, то Вы просто предложите выбрать 2 наиболее важных для него пункта. Объясните ему, что практически никогда проект не вписывается в три критерия. Никогда не бывает быстро, качественно, дешево. Как только она выберет два из трех, к третьему оставшемуся автоматом ставьте приставку «не». К примеру Ваш клиента выбрал «быстро, качественно», ставим приставку «не» к третьему, и получаем «быстро, качественно и НЕдешево».
Приведу еще пару:
«Небыстро, качественно, дешево»,
«Быстро, Некачественно, дешево».
Из моего опыта: я всегда сам выбираю два из трех, читая ТЗ и условия клиентов. Я вообще стараюсь доходчиво объяснять мою позицию для клиента, чтобы меньше вступать с ним в конфронтацию. Мое общение с клиентами, иногда чем-то схоже на общение с детьми. Но это происходит лишь в тех случаях, когда клиент ну уж совсем ведет себя как ребенок в магазине «Хочу и все!».

7. Не учитесь на реальных проектах.

Вернее так, доучивайтесь, но не постигайте новую специальность на новых проектах. Этот пункт пересекается с пунктом 1. Не берите проекты, в которых вы знаете как минимум 80%. Так как во время разработки Вы будете заниматься не только разработкой, но и изучением технологий, алгоритмов и приемов программирования. Не обучайтесь за чужой счет! Вам платят за разработку и только.
Из моего опыта: мы решили взять проект, который казался нам финансово выгодным. Но был один нюанс, мы плохо ориентировались в теме (документооборот) и в одном из языков разработки JavaScript(конкретно jQuery). Но подумали, что все очень просто и, что все можно легко изучить. Но не тут-то было! Не буду рассказывать про всю катастрофу, но в двух словах проект был сорван, выставлены штрафные санкции и было очень много баг-фиксинга, а также бесконечные переговоры с клиентом.

Часть 5. Финансовый аспект, партнерство и сотрудники

1. Это бизнес, детка!

Как бы Вам не хотелось, но Вы не можете отрицать, что ваша работа на себя – это не хобби, а это бизнес чистой воды. Примите это. Если Вы с пеной у рта будете доказывать, что вы работаете ради удовольствия, так сказать “for fun”, тогда я вообще не понимаю, зачем Вы читаете эту статью.
Из моего опыта: Для меня лично, люди, которые называют себя «вольными художниками» и, которых, не волнует финансовый вопрос их занятия, ассоциируются с такими хипстерами-лентяями. Мол, я такой независимый, работаю сам на себя, когда захочу и где захочу. Почему я вспомнил именно про хипстеров, потому что около полугода назад у нас в городе открывался open space co-working офис (если это можно так назвать). На открытие пришло очень много фрилансеров. Я видел фотоотчет, меня, слава Богу, там не было. На всех фотографиях были какие-то непонятные личности. Из разряда «я не такой как все, меня не интересуют деньги, а только занятие своим любимым делом». Я увидел несколько знакомых лиц. Так вот, эти личности себя громко называют фрилансерами, вольными художниками и очень сильно подчеркивают, что они не работают на дядю. Но в тот же момент они утверждают, что их не волнуют деньги и то, что им плевать на все законы бизнеса, экономики и ведения дел. Такие товарищи могут взять, а потом отказаться от проекта мотивируя чем-то вроде этого «Моя муза не пришла» или «Душа больше не лежит к этому проекту».
Если Вы стали работать на себя, то старайтесь вести дела как бизнесмен, а не как творческая личность.

2. Формирование цены.

Так как Вы занимаетесь бизнесом, то естественно, Вы должны уметь правильно считать стоимость за проект, за работу. Расчет стоимости проекта – это чуть ли не самая трудная задача в бизнесе. Каждый бизнесмен рассчитывает ее по-своему. Я расскажу ниже, как рассчитываю ее я, но перед этим хочу упомянуть про одну частую ошибку. Никогда не выпытывайте у клиента, сколько он может заплатить. Если клиент не говорит Вам бюджет проекта – это вовсе не значит, что он хочет Вас обмануть. Зачастую, клиент просто не знает реального ценника. Если Вы начнете говорить: «А сколько Вы готовы заплатить?» – это как минимум непрофессионально. Клиент начнет колебаться и сомневаться в Вас и уйдет к Вашим конкурентам.
Из моего опыта: Выше я писал, как я считаю срок выполнения проекта. Так вот, ценник я считаю следующим образом: во-первых: я делю время на две части оплачиваемое и неоплачиваемое. Из тех трех частей описанных в пункте 5 четвертой части, я беру деньги только за первую треть, то есть за разработку. Интеграция и баг-фиксинг – это все бесплатно. Баг-фиксинг – это понятно, клиент не должен платить за наши косяки. Интеграция – это отдельный момент. Тут больше психологии, в этот период, когда все отлично, система работает и вы вместе с клиентом интегрируете ее на клиентские машины, зачастую вы начинаете говорить на отвлеченные темы, которые приводят Вас и Вашего клиента на более доверительный уровень общения. Теперь, Вы не просто безликий разработчик из дальней неведомой страны, Вы реальный человек. В этот период клиент зачастую говорит, что ему хочется иметь еще одну систему или он хочет, чтобы Вы взглянули на существующую систему и ее проблемы и т.д. То есть он не хочет упускать Вас из виду. Так как клиенты не любят менять разработчиков, то они хотят, чтобы вы были постоянным исполнителем. Ладно. Вернемся к расчету стоимости.
К примеру: на проект нужно 100 человеко-часов на разработку. На проект Вы можете выделить одного специалиста. Ставка в час такого специалиста, скажем 20$. Вы закладываете маржу в стоимость часа специалиста, то есть прибыль компании, к примеру 5$. В итоге мы получаем 25$ в час, а суммарно за проект 2500$. Это лишь примерные цифры. Но суть того, как мы считаем ценник – реальный. Естественно в эти оплачиваемые часы не входит тестирование и интеграция.

3. Не будьте жадными.

Да-да, именно так не жадничайте. Не стоит «заламывать цену», когда только что Вы получили признание, а тем более если Вы только начали заниматься бизнесом. В нашем бизнесе редко, когда прокатывает такой трюк, который когда-то сделала фирма производящая сигареты марки “Parliament”. В двух словах у них были проблемы с продажами, и они провели ребрендинг, и просто-напросто повысили цену на сигареты. После этого продажи начали расти. К сожалению, в наше время такое редко удастся сделать.
Из моего опыта: так получилось, что я никогда не жадничал и выставлял ценник вполне соизмеримый реальному ценнику за проект. Но я видел, когда ко мне приходили клиенты и говорили, что работали они с другими компаниями, те компании начали расти и стали «заламывать» феерический ценник. И получалось, что клиент не мог платить столько, сколько хотела компания, и он уходил от них. То есть всегда держите себя в руках, с выбором ценника. Так как Вы можете потерять постоянного клиента и репутацию.

4. Выбирайте партнера не как друга, а как партнера.

Зачастую молодые бизнесмены ищут партнеров для будущего совместного бизнеса в своем кругу, среди друзей или родственников. Им кажется, что так будет проще и легче. Так-то оно так, но только на первом этапе. Когда компания только формируется. Дальше все будет сложнее. В любом случае в будущем у Вас или у Вашего партнера будут претензии, или ваши взгляды будут расходиться, а компромисс очень сложно найти. С близким человеком очень сложно спорить или ссорится из-за бизнеса, так как у Вас будет постоянная мысль о том, что Вы его можете потерять. И в итоге – это ни к чему хорошему не приведет. Вы можете потерять не только бизнес, но и друга. Поэтому при выборе партнера всегда помните, что вы можете разойтись по причинам связанным с бизнесом.
Из моего опыта: Со мной случилось также. Мой бывший бизнес-партнер – это мой друг. Но мы разошлись с ним миром и в нашем общении ничего не поменялось. Мне повезло. Меня он научил многим хорошим вещам и за это я ему благодарен. Я навсегда запомнил его фразу: «Саша, по отдельности мы можем добиться гораздо большего, чем мы сможем вместе». Мы остались друзьями, у нас нет обид и претензий друг к другу – это очень большое везение. Так как зачастую друзья, создающие бизнес, расстаются врагами и с кучей обид. Поэтому, чтобы не было проблем, на начальных этапах выбирайте себе партнера-единомышленника, а не партнера-друга.

5. Найм сотрудников.

Для всех руководителей ключевой проблемой становится найм сотрудников. Так как программисты народ специфичный, то к выбору сотрудника необходимо подходить еще более тщательно. Прежде чем нанять еще одного сотрудника подумайте над тем, а нужно ли Вам это? Нанимая сотрудника, Вы сознательно расширяете штат компании. Ваша компания со временем станет неповоротливым монстром. Бизнес – это война. А в реалиях нынешнего мира, войны не ведутся полками, дивизиями, и армиями. Войны ведутся за счет мобильных бригад, которые могут гораздо эффективнее справляться с поставленными задачами. Будьте мобильными.
Если же Вы все-таки окончательно решили нанять сотрудника, то на собеседовании обратите внимание на следующие вещи: адекватность, общительность, понимание темы разговора, скорость мышления.
Адекватность – тут все понятно, если человек приходит на собеседование и не понимает, что он тут делает или как-то неадекватно реагирует на ваши вопросы – значит мимо.
Общительность – если человек не умеет нормально общаться на отвлеченные, а тем более профессиональные темы на собеседовании, то представьте, как он будет вести себя в реальной жизни.
Понимание темы разговора – если Вы говорите об одном, а человек не понимает или пытается свернуть с темы разговора, то с такими людьми будет сложно сработаться, так как они в реальной работе будут делать не так как нужно, а как ему вздумается.
Скорость мышления – скорость мышления для ИТ-специалиста очень критична, на мой взгляд. Если человек не может быстро сориентироваться в ситуации на собеседовании, то как он будет ориентироваться на сложных и хитрых задачах?
Если человек подходит по всем вышеперечисленным критериям, то не забывайте еще про то, как он вольется в коллектив. Пусть даже Ваш кандидат гений, который идеально подходит по всем параметрам, но по первичной оценке он не совсем подходит к характеру Вашего коллектива, то лучше отказаться от него. Так как, придя в новый коллектив, этот человек может нарушить атмосферу в нем, и вся работа будет выполняться не так эффективно, как надо.

6. Прислушивайтесь к своим партнерам и сотрудникам.

Иметь свою точку зрения – это, безусловно, здорово, но если Вы напрочь отказываетесь от других мнений – это неправильно. Человеку свойственно «замыливать глаз», то есть очень долго решать проблему и не видеть других подходов, кроме одного. Прислушивайтесь к коллегам, ведь они могут посмотреть на проблему под другим углом и найти решение более простое, чем Ваше, либо дать идею для решения задачи.
Из моего опыта: Когда я еще работал «на дядю», у меня был шеф, который мнил из себя очень крутого разработчика, по сути он был больше хвастуном и оооочень посредственным программистом. Так вот этот товарищ отстал от технологий на тот момент лет так 15. В компании было разработано ПО, которое предназначалось для банков. Оно было разработано еще в 90-х и постоянно дорабатывалось под нужды клиентов. СУБД в этой системе была, мягко говоря, не самая распространенная. К сожалению, я не могу вспомнить название, вернее могу, но боюсь ошибиться. И получилось так, что в команду пришли новые программисты – тим-лиды, они пытались переубедить шефа в том, что не стоит продолжать разработку, используя эту СУБД, но ему было все равно. Так вот в один прекрасный момент поддержка этой СУБД прекратилась, а как следствие у компании, в которой я работал, появились проблемы с тем, что же делать дальше. Все это закончилось 2-х или 3-х летним переписыванием системы, кучей багов, потерей клиентов и т.п. А если бы шеф послушал программистов раньше на год или два, то все могло бы быть не так плачевно.

7. Создавайте побочную прибыль

Всем давно известно, что бизнес – это дело, единственной целью которого является заработок денег. Расширение финансовых потоков – это, несомненно, пик профессионализма и мастерства. Предлагайте больше, чем только одно направление. Работайте по всем фронтам. К примеру, Вы разработали какую-то большую систему для клиента. Выделите движок из нее, ищите, кому она будет интересна. Но тут есть одно НО. Не пытайтесь переключить свое внимание от текущих проектов на создание побочной прибыли. Это неправильно, так как, увлекшись созданием побочной прибыли Вы можете потерять основную.
Из моего опыта: Мы имеем два проекта, которые делались по заказу, а потом поставили на поток. Естественно, мы не продаем их, как есть, мы выделяли движки, а потом использовали их для создания очень похожих продуктов, то есть создавали побочную прибыль с использованием минимальных ресурсов. И эти действия внесли достаточно хорошую прибыль в наш бюджет.

8. Не пытайтесь конкурировать с монстрами

Просто не пытайтесь. У Вас не хватит ни сил, ни времени, ни желания. Того, что есть в крупных компаниях. Идите по своему пути, разрабатывайте то, что Вам интересно. Анализируйте конкурентов, перенимайте лучшее от них, но ни в коем случае не пытайтесь конкурировать с ними. Ищите недостатки у конкурентов и покрывайте их.
Из моего опыта: Так как я начинал свою независимую карьеру одержимый программированием, то я не особо задумывался о конкуренции. Я просто работал. Но по прошествии лет, когда мое увлечение превратилось в бизнес, я стал анализировать продукты конкурентов и пришел к выводу, что не стоит создавать аналоги продуктов конкурентов, а стоит покрывать те места, в которых конкурент слаб. Один из наших продуктов по сути является эдаким заменителем прямого конкурента, но только в очень узкой области. Мы не пытались сделать аналог, мы делали отдельный продукт, который удовлетворяет требования клиентов, которые не может покрыть система конкурента.

Вместо заключения

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

Спасибо за внимание.

С уважением,
Александр

Автор: vyadzmak

Источник