Бизнес – это игра или нет? Я думаю да. А у любой игры должны быть правила.
Привет Хабр, меня зовут Александр. Сегодня я хотел бы поделиться с вами о том, как надо или не надо вести бизнес в сфере IT. Данные заметки я извлек из собственного опыта. Я не буду писать здесь книжными и в тоже время, зачастую, пустыми и скучными фразами. Здесь будет только то, что я почерпнул для себя работая на поприще самостоятельной работы, то есть не на дядю. Вся статья будет поделена на части. Во всех частях кроме первой, материал будет изложен в виде заметок, после каждой заметки я буду приводить пример из моей работы, чтобы не быть голословным. Поехали!
Я уже 5 лет работаю только на себя. Сначала фрилансером, потом основал свою компанию. Начинал я с российского рынка фриланса, еще будучи студентом, не имея даже отдаленного понятия о бизнесе. Сначала делал очень маленькие проекты, потом перешел на уровень выше. А потом и вовсе перебрался на западные фриланс-биржи. За все это время я выполнил более 100 проектов точно, может чуть больше. Я работал с клиентами из множества стран: США, Великобритании, Австралии, Бразилии, Польши, Швеции, Испании, России, Италии, Японии, ЮАР, Израиля и т.д. Всех не буду перечислять, так как всех не упомню. Как вы видите география клиентов обширная, а это значит, что я могу сделать некоторые выводы о работе с клиентами, проектами, сотрудниками и, надеюсь, они будут полезным для вас.
Да, кстати, я специализируюсь на OCR, OMR, в последнее время наращиваю мощности в области документооборота.
Банально, но это так. Планирование – это одна из составляющих успешного бизнеса. Без планирования ваши дела будут похожи на комок ниток, который вы постоянно будете распутывать, а кто-то со стороны Вам будет подкидывать еще больше этих ниток. И это превратиться в бесконечную рутинную работу. Старайтесь каждый день составлять список задач на последующий день.
Из моего опыта: Определенное время, когда я работал с одним или двумя клиентами, я не вел никаких записей, планов, не составлял графики. Но с течением времени клиентов и задач становилось все больше, но я упорно пытался положиться на свою память. В конце концов, это привело к тому, что я забыл про одни переговоры, не подготовился к ним и, как следствие, провалил их. Еще был курьезный момент, когда я забыл имя клиента. Но там все обошлось, так как клиент оказался с чувством юмора.
После таких провалов я начал вести ежедневные планы, стал записывать имена клиентов, бюджеты и т.д.
Не пытайтесь нагрузить себя задачами на день, с которыми вы не сможете справиться. К примеру: Вы ставите себе задачу написать какой-либо класс, разработка которого занимает часов 8, то есть целый рабочий день. Не пытайтесь в этот список поставить параллельную задачу, к примеру, переговоры. Так как вы и класс не напишите, и переговоры будут скомканными. Мотивацию убивает в первую очередь нерешенные кочующие задачи. Если вы поставили себе задачу, к примеру, 1 марта, а она остается с Вами до 1 мая – это убивает. Такие задачи как кочевники, кочуют из одного дня в другой. Избавьтесь от них.
Из моего опыта: В первое время как я стал планировать свой график, я старался запихнуть в один день много задач. Сначала я гордился этим, мол я такой занятой. А потом я заметил, что у меня остались кочующие задачи, которые я назначил еще месяц назад, но так и не выполнил их. И это стало убивать мотивацию к работе. Поэтому я стараюсь планировать мой день адекватно. Соизмеримо моим силам и возможностям.
Как бы Вам не хотелось работать над интересной задачей, умейте выставлять приоритет вашим делам. В первую очередь решайте критичные и срочные задачи, а не те, которые Вам хочется. Так как не решив критичную задачу сегодня, возможно, вам уже не придётся решать интересную задачу завтра. Сделайте к примеру 4 категории задач: «Очень срочные», «Обычные», «Низкие по приоритету», «Когда-нибудь». И это упростит Вам жизнь.
Из моего опыта: В работе с клиентом из США мы старались потакать его требованиям, и ушли далеко от серьезных вещей. Его (клиента) интересовал только внешний вид программы, а мы, пойдя на уступки, потеряли уйму времени для того, чтобы программа была стилизована под цвета компании, вместо того, чтобы заниматься серьезными задачами, такими как разработка ядра программы. Итог: сдвиг сроков, потеря денег и очень напряженные отношения с клиентом.
Срочные задачи – это те задачи, которые очень часто решают судьбу всего проекта, компании, взаимоотношений с клиентом.
Из моего опыта: С нами связался потенциальный клиент, он предложил нам разработку одного интересного проекта. Мы обсудили примерный бюджет, сроки и пришли к предварительному соглашению. Он сказал, что вышлет детальное ТЗ, чтобы мы могли предметно разговаривать. Мы сказали «ОК». После получения ТЗ, мы благополучно про него забыли, так как в тот момент мы работали над другим проектом и задачи там были менее приоритетные. В итоге, нашему потенциальному клиенту надоело ждать, и он ушел к другим разработчикам. Мы потеряли перспективный проект из-за того, что отложили решение срочной задачи.
Отличный переговорщик – это такой человек, который в краткие сроки может склонить на свою сторону клиента. Но иногда попадаются очень капризные клиенты, которые по несколько раз переспрашивают и тянут время. Поэтому чтобы избежать конфликтов с другими вашими клиентами, инвесторами, партнерами, назначайте переговоры с интервалом не менее 3-х часов. И вы отдохнете и не надо будет судорожно смотреть на часы.
Из моего опыта: Я назначил переговоры с двумя клиентами. С одним на 16.00 с другим на 17.00. Я думал, что с первым мы закончим быстро и я со спокойной душой пойду ко второму клиенту. Но не тут-то было! У первого клиента как назло оказалась уйма вопросов, которые он хотел задать именно в этот день. А у второго клиента было окно только с 17.00 до 18.00. В итоге: с первым я нормально провел переговоры, а со вторым у нас начались недопонимания, которые мы впоследствии уладили. Но впредь я не назначаю переговоры с таким маленьким интервалом.
Всем хорошо известный принцип делегирования полномочий, задач и прочих дел, почему-то не у всех людей
приветствуется. Научитесь делегировать свои задачи, или задачи компании другими людям. Так как это приводит к «многопоточности», а все мы знаем, что многопоточное решение задач лучше однопоточного. Если вы научитесь правильно делегировать задачи другим людям, вы сможете более эффективно вести бизнес.
Из моего опыта: изначально я делегировал все юридические и бухгалтерские вопросы другим людям по двум причинам: во-первых у меня не было времени разбираться в законодательстве и бухгалтерском учете, а во-вторых просто я не люблю юриспруденцию и бух. учет. И поверьте, так гораздо проще, мне не надо составлять отчеты, договора и терять драгоценное время.
Большая ошибка всех начинающих бизнесменов – это подсчет прибыли, которую они еще не заработали. Причем не просто подсчет, а ее распределение между членами команды. Научитесь сдерживать себя от прогнозов. Если вы только начали вести переговоры о проекте, не надо сразу считать, что такую-то сумму вы потратите на ремонт офиса или машину. Просто работайте, не обращайте внимание на цифры в договоре. Представьте, что их нет. На сумму стоит обращать внимание тогда, когда проект на 85% готов. Только после этого. Так как часто бывает, что выплата по проекту может затянуться и ваши планы рухнут.
Из моего опыта: На одном из проектов мы обговорили сумму с клиентом, подписали договор и я начал считать куда же потратить эти деньги, но я не учитывал того, что этих денег еще нет. И, как обычно бывает, оплата затянулась, планы рухнули.
Отдавайте приоритет текущим задачам, а не последующим. Так как текущие задачи почти всегда связаны с последующими, нельзя перепрыгивать с одной задачи более ранней стадии на задачу более поздней стадии. Если эти две задачи взаимосвязаны. Как известно нельзя сначала родить ребенка, а только после этого его зачать.
Так и здесь, выполняйте задачи согласно стадиям и срокам, последовательно.
Из моего опыта: Когда я только начинал работать фрилансером, зачастую я через слово читал ТЗ. Мне хотелось поскорее заключить сделку и приступить к выполнению проекта. Оно так и происходило. Сделку заключали, а потом я более внимательно читал ТЗ и понимал, что есть проблемы. Благо я умею и умел быстро находить решения, поэтому проекты делались в срок. Но я перепрыгивал с текущей задачи (Чтение ТЗ) на следующую (заключение договора). И это приводило к конфузам.
Многие кто работал с клиентами, сталкивались с ситуацией, когда клиент мнит себя Богом. Особенно это касается менеджеров проекта. Клиенты иногда не ставят профильных работников для курирования проекта, а они нанимают или назначают менеджеров, которые в свою очередь довольно редко имеют профильное ИТ – образование. Но почему-то эти люди чаще всего мнят себя Богами ИТ- бизнеса. Особенно в моментах связанных с технической стороной проекта. Умейте отстаивать свою точку зрения. Не поддавайтесь давлению таких вот Богов.
Из моего опыта: на данный момент у нас есть открытый проект с клиентом из США, его курирует молодой менеджер. Вернее так – очень молодой и не очень умный менеджер. И он постоянно спорит лично со мной по всем мелочам, начиная с названия проекта заканчивая использованием языков и технологий. Я отстаиваю свою точку зрения и делаю так, как считаю нужным, потому что данный менеджер далек от разработки в принципе. Если я пойду у него на поводу, то придется переделывать процентов 80 проекта, а это значит, что мы не укладываемся в бюджет и несем потери.
Не давайте клиенту почувствовать власть над собой. По сути у Вас партнерские отношения. Он вам не начальник – он ваш клиент. И точка. Многие клиенты работают по принципу – кто платит, тот и музыку заказывает. Не позволяйте делать так. Потому что он сядет вам на шею.
Из моего опыта: Один из клиентов, пытался доказать мне, что я должен делать все, что он прикажет в любое время суток и без оплаты. Сначала я поддавался и пытался выполнять задачи в таком русле, но как только я понял, что этот клиент отбирает мое время (а следственно деньги) и нервы, нам пришлось расстаться. И я нисколько не сожалею об этом.
Запомните, не все ваши клиенты разбираются в ИТ. Старайтесь очень спокойно объяснять то или иное. Так как бывают очень глупые и недалекие клиенты в нашей ИТ-сфере, но очень умные и продвинутые в своей. С очень хорошими бюджетами.
Из моего опыта: На моей памяти был один клиент из Испании, который сделал заказ на проект. Человек сам владел логистической компанией и был очень далек от ИТ-сферы. На каждом этапе мы очень доходчиво объясняли ему «Что? Зачем? Как?». В итоге мы разработали ПО, которое, во-первых принесло нам деньги, а во-вторых толкнуло нас на новый этап развития компании.
Тут даже нечего объяснять. Соблюдение обещаний, сроков – это один из столпов ИТ-бизнеса. Это то, что формирует ваш имидж, то на что ваши клиенты обращают внимание. Делайте все для того, чтобы этого достичь. Если Вы сорвали сроки, то не надо оправдываться – это не поможет, а только усугубит ситуацию. Попробуйте объяснить клиенту почему вы сорвали дедлайн. Но только без оправданий.
Из моего опыта: Мы сорвали сроки на одном проекте. Вернее нет. Не так. Мы ОЧЕНЬ! сорвали сроки на одном проекте. Попробовали оправдаться, мол неправильно оценили ситуацию, надо переписывать DAL, BLL заново (хотя в ТЗ этого не было). Не помогло – это была наша оплошность, и клиент настаивал на штрафных санкциях. В итоге мы предложили клиенту сделать часть функционала бесплатно, чтобы загладить вину. Он согласился. Но осадок уже остался.
Я вообще не приверженец общения в чатах, с помощью почты и т.д. я стараюсь общаться голосом либо лично, чтобы проще и быстрее договариваться о чем-либо. В общении голосом или лично, вы можете слышать или видеть как меняется настроение, интонация у вашего собеседника, и Вы можете подстроиться под это.
Этот пункт какой-то «камень преткновения» для многих молодых бизнесменов. Стараясь угодить клиенту, молодые ИТ-бизнесмены не умеют говорить «Нет», но это в итоге приводит к печальному результату. Бизнесмены теряют деньги, время, а иногда клиентов, из-за неумения сказать «Нет».
Из моего опыта: На одном из проектов, произошел забавный случай, мы завершили проект, деньги были переведены, ТЗ выполнено в полном объеме. Все, кажется, проект закрыт, но не тут-то было! Через недели полторы по окончанию проекта, мне на мыло приходит письмо, с вложенным PDF-файлом. В этом файле были указаны спецификации нового функционала. И этот функционал должен быть внедрен бесплатно! Я просто был в шоке от этого, так как спецификации по новому функционалу были соизмеримы с ТЗ. То есть с оплаченной работой. Естественно я отказался, объяснив клиенту, что это новая работа, не связанная с первоначальным ТЗ. Он долго возмущался, но в итоге отказался от разработки данного функционала. Баги и недочеты мы исправляли бесплатно.
Если клиент вам чем-то не нравится, ваша интуиция подсказывает, что не стоит работать с ним – верьте ей. Если на самых ранних этапах общения с клиентами у Вас возникают сомнения, лучше откажитесь от такого клиента.
Из моего опыта: я отказывался от работы с клиентами по разным причинам, но назову несколько из них: неумение правильно излагать мысли, неуместный торг, пренебрежительное отношение, отказ от написания ТЗ, очень долгая обратная связь, наглость.
И в этих случаях я всегда был прав, что отказывался. Так как я не получал головную боль от этих клиентов и выполнял новые задачи.
Если вы начали работать с клиентом, то постарайтесь оставить у него только положительные моменты от работы с вами. Так как в будущем он скорее придет к вам нежели будет искать другого исполнителя.
Многие небольшие компании и отдельные фрилансеры грешат тем, что они занимаются всем. С моей точки зрения – это тупиковый путь развития. Так как заниматься всем невозможно. Вы не сможете конкурировать с нишевой компанией или отдельным разработчиком, если вы занимаетесь всем. Невозможно сесть на 5 стульев одновременно.
Из моего опыта: Как я писал выше, моя основная специализация – это распознавание. До выбора ниши я занимался всем. Но это не очень хорошо получалось, так как мне приходилось в новом проекте изучать технологии, инструменты и аспекты данной задачи. По сути, выбор ниши у меня произошел случайно, после написания дипломной работы. А она была на тему «Распознавание текста с использованием нейронных сетей Хопфилда и Хэмминга». После этого я стал использовать свою библиотеку в проектах. Я стал чаще брать проекты, связанные с распознаванием. А впоследствии сконцентрировался только на них. Естественно я работаю над проектами, в которых распознавание – это лишь малая часть. Но все же. Я оттачиваю свое мастерство от проекта к проекту, а так как это бизнес – я использую свои наработки в новых проектах, чем значительно сокращаю время разработки и получаю бОльшую прибыль за меньший срок.
Упрощайте все по максимуму. Начиная от интерфейса заканчивая архитектурой. Никому не нужно, чтобы все было запутано. Чем проще – тем лучше.
Из моего опыта: самым лучшим проектом в плане интерфейса, юзабилити и архитектуры, я считаю проект, который был разработан для испанского клиента, о нем я писал выше. Я потратил две недели на разработку архитектуры, но ни сколько не жалею об этом. Так как я до сих пор использую этот движок в других проектах и иногда я просто продаю его. И та простота, которую я заложил в самом начале, она помогла мне адаптировать движок под мои нужды в самые кратчайшие сроки. Хотя испанский проект был очень сложным.
При проектировании более или менее крупного проекта, не пытайтесь охватить все. Это бесполезно! Вы не сможете учесть все нюансы. Сконцентрируйтесь над основными частями системы. Опишите главные моменты и задачи. И приступайте к разработке. Такой подход сравним с подходом скульпторов. Из глыбы они сначала формируют примерный силуэт, а потом, двигаясь от одной части к другой, делают силуэт уже более схожим с реальным объектом. И только в конце они детализируют свою скульптуру. Так должно быть и у Вас. Сделайте большие части программы, а потом разбивайте и дорабатывайте их, делайте более схожими с реальностью.
Из моего опыта: Когда я приступаю к разработке нового проекта, сначала я разделяю его на несколько логических частей. После чего приступаю к разработке. Во время разработки я делю эти логические части на более мелкие и внедряю их. И повторяю это на каждом этапе, делая части более мелкими. Этапы я повторяю до неделимого состояния этих частей.
Делайте все свои проекты так, чтобы впоследствии их можно было очень просто масштабировать. А также делайте их модульными. То есть разделенными на несколько логических модулей.
Масштабируемость позволит Вам легко расширить функционал системы, а модульность даст возможность выделить какую-то функциональность, к примеру, в отдельную библиотеку и использовать в других проектах, чем сократит время разработки.
Из моего опыта: я в принципе всегда разделяю проект на маленькие части, которые впоследствии использую в других разработках. Так я делаю везде, поэтому писать про конкретный случай не буду.
Я описал несколько важных частей любого ИТ-бизнеса. «Организация работы», «Клиенты», «Проекты». Раздел «Проекты» я не стал раздувать, так как статья получилась достаточно большая. Если уважаемое Хабр-сообщество захочет продолжения статьи, то я с удовольствием ее напишу и поделюсь своим опытом. Если честно, то я не стал включать в данную статью пункты «Сотрудники и партнеры», «Финансовый аспект», и как писал выше, не стал раздувать пункт «Проекты» только потому, что не знаю как воспримет мою статью Хабр.
Надеюсь, Вы нашли в этой статье что-нибудь полезное и почерпнули какие-то новые знания из нее и потратили свое время не зря.
Спасибо за внимание.
С уважением,
Александр
Привет Хабр, меня зовут Александр. Сегодня я хотел бы поделиться с вами о том, как надо или не надо вести бизнес в сфере IT. Данные заметки я извлек из собственного опыта. Я не буду писать здесь книжными и в тоже время, зачастую, пустыми и скучными фразами. Здесь будет только то, что я почерпнул для себя работая на поприще самостоятельной работы, то есть не на дядю. Вся статья будет поделена на части. Во всех частях кроме первой, материал будет изложен в виде заметок, после каждой заметки я буду приводить пример из моей работы, чтобы не быть голословным. Поехали!
Часть 1. Моя краткая история.
Я уже 5 лет работаю только на себя. Сначала фрилансером, потом основал свою компанию. Начинал я с российского рынка фриланса, еще будучи студентом, не имея даже отдаленного понятия о бизнесе. Сначала делал очень маленькие проекты, потом перешел на уровень выше. А потом и вовсе перебрался на западные фриланс-биржи. За все это время я выполнил более 100 проектов точно, может чуть больше. Я работал с клиентами из множества стран: США, Великобритании, Австралии, Бразилии, Польши, Швеции, Испании, России, Италии, Японии, ЮАР, Израиля и т.д. Всех не буду перечислять, так как всех не упомню. Как вы видите география клиентов обширная, а это значит, что я могу сделать некоторые выводы о работе с клиентами, проектами, сотрудниками и, надеюсь, они будут полезным для вас.
Да, кстати, я специализируюсь на OCR, OMR, в последнее время наращиваю мощности в области документооборота.
Часть 2. Организация работы
1. Планируйте.
Банально, но это так. Планирование – это одна из составляющих успешного бизнеса. Без планирования ваши дела будут похожи на комок ниток, который вы постоянно будете распутывать, а кто-то со стороны Вам будет подкидывать еще больше этих ниток. И это превратиться в бесконечную рутинную работу. Старайтесь каждый день составлять список задач на последующий день.
Из моего опыта: Определенное время, когда я работал с одним или двумя клиентами, я не вел никаких записей, планов, не составлял графики. Но с течением времени клиентов и задач становилось все больше, но я упорно пытался положиться на свою память. В конце концов, это привело к тому, что я забыл про одни переговоры, не подготовился к ним и, как следствие, провалил их. Еще был курьезный момент, когда я забыл имя клиента. Но там все обошлось, так как клиент оказался с чувством юмора.
После таких провалов я начал вести ежедневные планы, стал записывать имена клиентов, бюджеты и т.д.
2. Не составляйте большие списки задач.
Не пытайтесь нагрузить себя задачами на день, с которыми вы не сможете справиться. К примеру: Вы ставите себе задачу написать какой-либо класс, разработка которого занимает часов 8, то есть целый рабочий день. Не пытайтесь в этот список поставить параллельную задачу, к примеру, переговоры. Так как вы и класс не напишите, и переговоры будут скомканными. Мотивацию убивает в первую очередь нерешенные кочующие задачи. Если вы поставили себе задачу, к примеру, 1 марта, а она остается с Вами до 1 мая – это убивает. Такие задачи как кочевники, кочуют из одного дня в другой. Избавьтесь от них.
Из моего опыта: В первое время как я стал планировать свой график, я старался запихнуть в один день много задач. Сначала я гордился этим, мол я такой занятой. А потом я заметил, что у меня остались кочующие задачи, которые я назначил еще месяц назад, но так и не выполнил их. И это стало убивать мотивацию к работе. Поэтому я стараюсь планировать мой день адекватно. Соизмеримо моим силам и возможностям.
3. Разделяйте задачи по важности.
Как бы Вам не хотелось работать над интересной задачей, умейте выставлять приоритет вашим делам. В первую очередь решайте критичные и срочные задачи, а не те, которые Вам хочется. Так как не решив критичную задачу сегодня, возможно, вам уже не придётся решать интересную задачу завтра. Сделайте к примеру 4 категории задач: «Очень срочные», «Обычные», «Низкие по приоритету», «Когда-нибудь». И это упростит Вам жизнь.
Из моего опыта: В работе с клиентом из США мы старались потакать его требованиям, и ушли далеко от серьезных вещей. Его (клиента) интересовал только внешний вид программы, а мы, пойдя на уступки, потеряли уйму времени для того, чтобы программа была стилизована под цвета компании, вместо того, чтобы заниматься серьезными задачами, такими как разработка ядра программы. Итог: сдвиг сроков, потеря денег и очень напряженные отношения с клиентом.
4. Не откладывайте срочные задачи.
Срочные задачи – это те задачи, которые очень часто решают судьбу всего проекта, компании, взаимоотношений с клиентом.
Из моего опыта: С нами связался потенциальный клиент, он предложил нам разработку одного интересного проекта. Мы обсудили примерный бюджет, сроки и пришли к предварительному соглашению. Он сказал, что вышлет детальное ТЗ, чтобы мы могли предметно разговаривать. Мы сказали «ОК». После получения ТЗ, мы благополучно про него забыли, так как в тот момент мы работали над другим проектом и задачи там были менее приоритетные. В итоге, нашему потенциальному клиенту надоело ждать, и он ушел к другим разработчикам. Мы потеряли перспективный проект из-за того, что отложили решение срочной задачи.
5. Не назначайте переговоры с маленьким интервалом.
Отличный переговорщик – это такой человек, который в краткие сроки может склонить на свою сторону клиента. Но иногда попадаются очень капризные клиенты, которые по несколько раз переспрашивают и тянут время. Поэтому чтобы избежать конфликтов с другими вашими клиентами, инвесторами, партнерами, назначайте переговоры с интервалом не менее 3-х часов. И вы отдохнете и не надо будет судорожно смотреть на часы.
Из моего опыта: Я назначил переговоры с двумя клиентами. С одним на 16.00 с другим на 17.00. Я думал, что с первым мы закончим быстро и я со спокойной душой пойду ко второму клиенту. Но не тут-то было! У первого клиента как назло оказалась уйма вопросов, которые он хотел задать именно в этот день. А у второго клиента было окно только с 17.00 до 18.00. В итоге: с первым я нормально провел переговоры, а со вторым у нас начались недопонимания, которые мы впоследствии уладили. Но впредь я не назначаю переговоры с таким маленьким интервалом.
6. Делегируйте.
Всем хорошо известный принцип делегирования полномочий, задач и прочих дел, почему-то не у всех людей
приветствуется. Научитесь делегировать свои задачи, или задачи компании другими людям. Так как это приводит к «многопоточности», а все мы знаем, что многопоточное решение задач лучше однопоточного. Если вы научитесь правильно делегировать задачи другим людям, вы сможете более эффективно вести бизнес.
Из моего опыта: изначально я делегировал все юридические и бухгалтерские вопросы другим людям по двум причинам: во-первых у меня не было времени разбираться в законодательстве и бухгалтерском учете, а во-вторых просто я не люблю юриспруденцию и бух. учет. И поверьте, так гораздо проще, мне не надо составлять отчеты, договора и терять драгоценное время.
7. Не делите шкуру не убитого медведя.
Большая ошибка всех начинающих бизнесменов – это подсчет прибыли, которую они еще не заработали. Причем не просто подсчет, а ее распределение между членами команды. Научитесь сдерживать себя от прогнозов. Если вы только начали вести переговоры о проекте, не надо сразу считать, что такую-то сумму вы потратите на ремонт офиса или машину. Просто работайте, не обращайте внимание на цифры в договоре. Представьте, что их нет. На сумму стоит обращать внимание тогда, когда проект на 85% готов. Только после этого. Так как часто бывает, что выплата по проекту может затянуться и ваши планы рухнут.
Из моего опыта: На одном из проектов мы обговорили сумму с клиентом, подписали договор и я начал считать куда же потратить эти деньги, но я не учитывал того, что этих денег еще нет. И, как обычно бывает, оплата затянулась, планы рухнули.
8. Концентрируйтесь на текущих, а не на последующих задачах.
Отдавайте приоритет текущим задачам, а не последующим. Так как текущие задачи почти всегда связаны с последующими, нельзя перепрыгивать с одной задачи более ранней стадии на задачу более поздней стадии. Если эти две задачи взаимосвязаны. Как известно нельзя сначала родить ребенка, а только после этого его зачать.
Так и здесь, выполняйте задачи согласно стадиям и срокам, последовательно.
Из моего опыта: Когда я только начинал работать фрилансером, зачастую я через слово читал ТЗ. Мне хотелось поскорее заключить сделку и приступить к выполнению проекта. Оно так и происходило. Сделку заключали, а потом я более внимательно читал ТЗ и понимал, что есть проблемы. Благо я умею и умел быстро находить решения, поэтому проекты делались в срок. Но я перепрыгивал с текущей задачи (Чтение ТЗ) на следующую (заключение договора). И это приводило к конфузам.
Часть 3. Клиенты
1. Клиент не всегда прав.
Многие кто работал с клиентами, сталкивались с ситуацией, когда клиент мнит себя Богом. Особенно это касается менеджеров проекта. Клиенты иногда не ставят профильных работников для курирования проекта, а они нанимают или назначают менеджеров, которые в свою очередь довольно редко имеют профильное ИТ – образование. Но почему-то эти люди чаще всего мнят себя Богами ИТ- бизнеса. Особенно в моментах связанных с технической стороной проекта. Умейте отстаивать свою точку зрения. Не поддавайтесь давлению таких вот Богов.
Из моего опыта: на данный момент у нас есть открытый проект с клиентом из США, его курирует молодой менеджер. Вернее так – очень молодой и не очень умный менеджер. И он постоянно спорит лично со мной по всем мелочам, начиная с названия проекта заканчивая использованием языков и технологий. Я отстаиваю свою точку зрения и делаю так, как считаю нужным, потому что данный менеджер далек от разработки в принципе. Если я пойду у него на поводу, то придется переделывать процентов 80 проекта, а это значит, что мы не укладываемся в бюджет и несем потери.
2. Воспринимайте клиентов не как своих начальников, а как партнеров.
Не давайте клиенту почувствовать власть над собой. По сути у Вас партнерские отношения. Он вам не начальник – он ваш клиент. И точка. Многие клиенты работают по принципу – кто платит, тот и музыку заказывает. Не позволяйте делать так. Потому что он сядет вам на шею.
Из моего опыта: Один из клиентов, пытался доказать мне, что я должен делать все, что он прикажет в любое время суток и без оплаты. Сначала я поддавался и пытался выполнять задачи в таком русле, но как только я понял, что этот клиент отбирает мое время (а следственно деньги) и нервы, нам пришлось расстаться. И я нисколько не сожалею об этом.
3. Соблюдайте спокойствие.
Запомните, не все ваши клиенты разбираются в ИТ. Старайтесь очень спокойно объяснять то или иное. Так как бывают очень глупые и недалекие клиенты в нашей ИТ-сфере, но очень умные и продвинутые в своей. С очень хорошими бюджетами.
Из моего опыта: На моей памяти был один клиент из Испании, который сделал заказ на проект. Человек сам владел логистической компанией и был очень далек от ИТ-сферы. На каждом этапе мы очень доходчиво объясняли ему «Что? Зачем? Как?». В итоге мы разработали ПО, которое, во-первых принесло нам деньги, а во-вторых толкнуло нас на новый этап развития компании.
4. Выполняйте обещания, сроки и не ищите оправданий.
Тут даже нечего объяснять. Соблюдение обещаний, сроков – это один из столпов ИТ-бизнеса. Это то, что формирует ваш имидж, то на что ваши клиенты обращают внимание. Делайте все для того, чтобы этого достичь. Если Вы сорвали сроки, то не надо оправдываться – это не поможет, а только усугубит ситуацию. Попробуйте объяснить клиенту почему вы сорвали дедлайн. Но только без оправданий.
Из моего опыта: Мы сорвали сроки на одном проекте. Вернее нет. Не так. Мы ОЧЕНЬ! сорвали сроки на одном проекте. Попробовали оправдаться, мол неправильно оценили ситуацию, надо переписывать DAL, BLL заново (хотя в ТЗ этого не было). Не помогло – это была наша оплошность, и клиент настаивал на штрафных санкциях. В итоге мы предложили клиенту сделать часть функционала бесплатно, чтобы загладить вину. Он согласился. Но осадок уже остался.
5. Старайтесь больше общаться с клиентом.
Я вообще не приверженец общения в чатах, с помощью почты и т.д. я стараюсь общаться голосом либо лично, чтобы проще и быстрее договариваться о чем-либо. В общении голосом или лично, вы можете слышать или видеть как меняется настроение, интонация у вашего собеседника, и Вы можете подстроиться под это.
6. Умейте сказать «Нет».
Этот пункт какой-то «камень преткновения» для многих молодых бизнесменов. Стараясь угодить клиенту, молодые ИТ-бизнесмены не умеют говорить «Нет», но это в итоге приводит к печальному результату. Бизнесмены теряют деньги, время, а иногда клиентов, из-за неумения сказать «Нет».
Из моего опыта: На одном из проектов, произошел забавный случай, мы завершили проект, деньги были переведены, ТЗ выполнено в полном объеме. Все, кажется, проект закрыт, но не тут-то было! Через недели полторы по окончанию проекта, мне на мыло приходит письмо, с вложенным PDF-файлом. В этом файле были указаны спецификации нового функционала. И этот функционал должен быть внедрен бесплатно! Я просто был в шоке от этого, так как спецификации по новому функционалу были соизмеримы с ТЗ. То есть с оплаченной работой. Естественно я отказался, объяснив клиенту, что это новая работа, не связанная с первоначальным ТЗ. Он долго возмущался, но в итоге отказался от разработки данного функционала. Баги и недочеты мы исправляли бесплатно.
7. Отказывайтесь от «смущающих» клиентов.
Если клиент вам чем-то не нравится, ваша интуиция подсказывает, что не стоит работать с ним – верьте ей. Если на самых ранних этапах общения с клиентами у Вас возникают сомнения, лучше откажитесь от такого клиента.
Из моего опыта: я отказывался от работы с клиентами по разным причинам, но назову несколько из них: неумение правильно излагать мысли, неуместный торг, пренебрежительное отношение, отказ от написания ТЗ, очень долгая обратная связь, наглость.
И в этих случаях я всегда был прав, что отказывался. Так как я не получал головную боль от этих клиентов и выполнял новые задачи.
8. Замыкайте клиента на себе.
Если вы начали работать с клиентом, то постарайтесь оставить у него только положительные моменты от работы с вами. Так как в будущем он скорее придет к вам нежели будет искать другого исполнителя.
Часть 4. Проекты
1. Выберите нишу.
Многие небольшие компании и отдельные фрилансеры грешат тем, что они занимаются всем. С моей точки зрения – это тупиковый путь развития. Так как заниматься всем невозможно. Вы не сможете конкурировать с нишевой компанией или отдельным разработчиком, если вы занимаетесь всем. Невозможно сесть на 5 стульев одновременно.
Из моего опыта: Как я писал выше, моя основная специализация – это распознавание. До выбора ниши я занимался всем. Но это не очень хорошо получалось, так как мне приходилось в новом проекте изучать технологии, инструменты и аспекты данной задачи. По сути, выбор ниши у меня произошел случайно, после написания дипломной работы. А она была на тему «Распознавание текста с использованием нейронных сетей Хопфилда и Хэмминга». После этого я стал использовать свою библиотеку в проектах. Я стал чаще брать проекты, связанные с распознаванием. А впоследствии сконцентрировался только на них. Естественно я работаю над проектами, в которых распознавание – это лишь малая часть. Но все же. Я оттачиваю свое мастерство от проекта к проекту, а так как это бизнес – я использую свои наработки в новых проектах, чем значительно сокращаю время разработки и получаю бОльшую прибыль за меньший срок.
2. Простота.
Упрощайте все по максимуму. Начиная от интерфейса заканчивая архитектурой. Никому не нужно, чтобы все было запутано. Чем проще – тем лучше.
Из моего опыта: самым лучшим проектом в плане интерфейса, юзабилити и архитектуры, я считаю проект, который был разработан для испанского клиента, о нем я писал выше. Я потратил две недели на разработку архитектуры, но ни сколько не жалею об этом. Так как я до сих пор использую этот движок в других проектах и иногда я просто продаю его. И та простота, которую я заложил в самом начале, она помогла мне адаптировать движок под мои нужды в самые кратчайшие сроки. Хотя испанский проект был очень сложным.
3. От большего к меньшему.
При проектировании более или менее крупного проекта, не пытайтесь охватить все. Это бесполезно! Вы не сможете учесть все нюансы. Сконцентрируйтесь над основными частями системы. Опишите главные моменты и задачи. И приступайте к разработке. Такой подход сравним с подходом скульпторов. Из глыбы они сначала формируют примерный силуэт, а потом, двигаясь от одной части к другой, делают силуэт уже более схожим с реальным объектом. И только в конце они детализируют свою скульптуру. Так должно быть и у Вас. Сделайте большие части программы, а потом разбивайте и дорабатывайте их, делайте более схожими с реальностью.
Из моего опыта: Когда я приступаю к разработке нового проекта, сначала я разделяю его на несколько логических частей. После чего приступаю к разработке. Во время разработки я делю эти логические части на более мелкие и внедряю их. И повторяю это на каждом этапе, делая части более мелкими. Этапы я повторяю до неделимого состояния этих частей.
4. Модульность и масштабируемость.
Делайте все свои проекты так, чтобы впоследствии их можно было очень просто масштабировать. А также делайте их модульными. То есть разделенными на несколько логических модулей.
Масштабируемость позволит Вам легко расширить функционал системы, а модульность даст возможность выделить какую-то функциональность, к примеру, в отдельную библиотеку и использовать в других проектах, чем сократит время разработки.
Из моего опыта: я в принципе всегда разделяю проект на маленькие части, которые впоследствии использую в других разработках. Так я делаю везде, поэтому писать про конкретный случай не буду.
Заключение
Я описал несколько важных частей любого ИТ-бизнеса. «Организация работы», «Клиенты», «Проекты». Раздел «Проекты» я не стал раздувать, так как статья получилась достаточно большая. Если уважаемое Хабр-сообщество захочет продолжения статьи, то я с удовольствием ее напишу и поделюсь своим опытом. Если честно, то я не стал включать в данную статью пункты «Сотрудники и партнеры», «Финансовый аспект», и как писал выше, не стал раздувать пункт «Проекты» только потому, что не знаю как воспримет мою статью Хабр.
Надеюсь, Вы нашли в этой статье что-нибудь полезное и почерпнули какие-то новые знания из нее и потратили свое время не зря.
Спасибо за внимание.
С уважением,
Александр