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

Стартап или как найти программиста, если ты чайник?

IT-консалтинг: где найти программиста или айтишника онлайн для решения задач бизнеса, запуска стартапа в интернете или решения частных задач. Обзор популярных вариантов и сервисов + собственный опыт1. Я бы искал на апворке на почасовку частного специалиста, т.к. по сути вам нужен человек в штат, отдавать на аутсорс основной кусок затеи мне кажется не лучшая идея. 2. Думаю не нужен. Я бы разбил бы разработку на недельные итерации, и самостоятельно решал бы на месте что и как делать со специалистами. 3. Есть такие специалисты, называются full stack.

Я бы рекомендовал смотреть на 'JavaScript full stack'. И строить все на JavaScript, например: — backend : nodejs, express, postgresql, sequelize. делать rest api, само api документировать в swagger — frontend: angular2, sass, jade — mobile: NativeScript / Appcelerator Titanium Разработку строить спринтами (см. Agile ), т.е.

раз в неделю созвон по скайпу, вам показывают демо того что сделано за неделю, вы обсуждаете ситуацию на проекет, согласовываете, план работ на следующую неделю. На upwork, как раз, 1 раз в неделю снимаются деньги с карты. Нанять рекомендовал бы двух специалистов, один делает backend, другой frontend.

Тогда меньше шансов, что один будет вас за нос водить, плюс конкуренция за крутость в команде :). Можете взять на 20-30 часов в неделю, производительность снизится меньше чем затраты 🙂 Того, что делает backend желательно найти поопытнее, т.к. backend важнее правильно спроектировать.

Цены фрилансеров на upwork грубо говоря 15-40 $/h, скажем 1 за 30$ на 20 часов в неделю (backend), другой за 25$ на 30 часов в неделю, 5400$ в месяц.

Предположим 2 месяца на MVP, потом еще 4 на допил, итого 5400$ * 6 мес = 32k Можете поискать на местных биржах, будет дешевле, наверное, только я не знаю, какой специалист согласится работать дешевле, если рядом можно дороже, а об upwork знают все :). 4. Возможно моки экранов / дизайн

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

компании берут больше, часто в разы. Смотрите по финансам.

Риск попасть на компанию, которая запорет проект, такой же как и попасть на безответственного разраба Современные фреймворки дают хорошую скорость разработки — вначале проекта, один хороший разраб может запилить львиную часть функционала аналитик нужен если вы не понимаете, что вы хотите, или не можете создать процессKISS — keep it simple stupid.

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

В любом случае потребуется разобраться во всем самим — во избежании обмана

Нравится 3 Комментировать1. я бы искал студию, с ней хоть можно договор заключить и прописать ответственность сторон (но студия будет дороже естественно и точно также может налажать) 2.

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

Хорошего, детального тз будет достаточно, но есть момент. Если вы планируете запустить MVP, собрать фидбек и потом переписать начисто, то достаточно ТЗ.

Если же вы хотите потом итеративно MVP допиливать, то кроме тз очень желательно указать хотябы общие направления планируемого развитие, ибо прототип по голому ТЗ скорей всего будет написан не слишком гибким/расширяемым.

4. По хорошему вам нужен напарник с технической експертизой заинтересованный в развиит дела, а не наемный тех-директор.

1) Почитайте ответы на похожий вопрос, Довериться команде или создать команду? 2) Аналитик не обязателен, но найти хорошего программиста который еще и хорошо составляет ТЗ — в два раза сложнее 3) Зависит от сроков и бюджета, при желании можно нанять fullstack специалиста, а вот по очереди нанимать идея плохая, первый (или второй) может оказаться слабым, но некому будет об этом сказать, придется переделывать. 4) Макеты дизайна

5) Нужен

Нравится 2 КомментироватьНасчет отмели от долевого участия — это правильное решение. Если есть деньги на разработку — то это гораздо больше гарантий получение результата. Частник — дешевле. Компания — дороже. Без разницы кто будет делать. MVP — вполне по силам одному. Нет. Для MVP вся аналитика — это вы + программист. Лишние люди тут не нужны.

Найдете одного. Спланируете с ним как будет. Определитесь с ним нужен ли второй. Деньги. И ответы на много вопросов по ходу написания. Написать простым русским языком. Вкратце основные принципы. ТЗ лучше оформлять уже в паре с выбранным программистом.

А чем технический директор будет отличаться от программиста в плане оценки квалификации технического директора? Это на самом деле большая проблема. Нужно чтобы вам бы посоветовал кто нибудь квалифицированный и доверенный (заинтересованный).

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

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

И сотрудник-исполнитель хуже работает, чем фриленсер.

Нравится 2 КомментироватьЕсли вы собираетесь разрабатывать сайт + мобильное приложение, имеет смысл писать REST API на бэкэндэ, чтобы использовать для двух платформ. Соответственно, фронт придется писать на React.js, Angular.js либо на Vue.js. Если напишете на React.js, затем можно будет использовать React Native для приложения.

Самым первым шагом является нахождение дизайнера, который сможет выслушать вас, посмотреть на ТЗ, учесть все пожелания и сделать первые дизайн-макеты. ТЗ вы можете составить сами, просто впишите туда то, что вы хотите видеть в MVP и не больше. Обычно, на этой стадии закладывается основная концепция + функционал для MVP.

Также, если вы планируете делать MVP — по времени, это займет около 3 месяцев. При этом, не забываем что делаем максимально урезанную версию с минимальным функционалом + максимально демпингуем на затратах. Затем вы уже посмотрите, имеет ли смысл развивать продукт. Дизайнер сделает дизайн MPV за 50к.

Бэкэнд разработчик средней руки может написать для вас бэк с REST API за 50к в месяц. Фронтэнд разработчик напишет фронт на React.js также за 50к в месяц.

По-поводу ваших конкурентов — видно, что сайт поддерживается / развивается очень медленно либо он заброшен. На главной в хедере есть битые ссылки (франшиза), в футере не сменили год.

Хотя, конечно, это все косвенные факторы. Но конкуренты были, и всегда будут, бояться их смысла особого нет. Haters gonna hate.

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

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

Итого:

50к за дизайн + 150к за бэкэнд (3 месяца MVP) + 150к за фронт (3 месяца MVP) + 100к запаса = 450к

А вот я в описании увидел тупо тикет-менеджер — ведь это основная функция данного сервиса. И на мой взгляд, имеет смысл сконцентрироваться на этой одной функции как основной и сделать её максимально хорошо, а все остальное развивать/добавлять по мере надобности.

Самую большую головную боль вы получите с прайсами — ибо все делают их как хотят, в своих формата, программах, привычках, «мне так нравится» и других экселях/1С и прочее. И придется делать поддержку кучи форматов и всякие другие малоприятные вещи.

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

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

По стоимости: если заказывать у нас (имеется ввиду в России) — то разработка с нуля примерно так и обойдется, как сказал Артём Иннокентьев — в полмиллиона, плюс-минус. Если заказывать на апворке или какой-то другой международной бирже, то стоимость конечно будет несколько выше — многое зависит от имеющегося бюджета и сколько готовы ждать. Рассчитывать надо примерно от $15-20к. Плюс, наших разработчиков надо будет привлекать в любом случае — перевод, техподдержка, и прочее.

По ТЗ: да, вам нужен хороший аналитик, который разберется в вашей «кухне» и конвертирует ваши хотелки в конкретное ТЗ.

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

Если есть желание можем приватно пообщаться на данную тему — если бюджет есть, время не горит, ну а мне в целом интересен проект (фрилансер, фуллстек).

Технари такие технари. Сразу начинают накидывать технических подробностей, фронтенд, бэкэнд. Один даже сразу деньги посчитал, 3 месяца )) Вот так придумал цифру, перемножил ее на ставку, тоже придуманную, и получил какую-то сумму. Отлично! Теперь все ясно. По факту, начинать нужно с дизайна. На дизайне вылезет куча вопросов и куча моментов, о которых вы даже не думали.

После создания дизайна прототипа, желательно еще интерактивного, можно составить описание продукта, вашими словами. Именно это описание продукта будет базой для технарей. После сами технари пишут ТЗ и говорят, вот на эту фичу нужно будет 10 дней, на эту примерно 5 и т.д. И после этого у вас появляются какие-то сроки.

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

Если денех нет на команду, тогда ищите дизайнера, лучше с навыками разработки интерфейса UI/UX.

С ним проработаете идею, опишите ее, выкинете все ненужное. С этими макетами можно уже или к технарям или искать команду менеджер+ технари.

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

Шишки и грабли — помогут. Других методов нет.

Нравится 2 11 комментариевБлагодарю всех за конструктивные и оперативные ответы! За последний час мы узнали больше, чем за всю прошлую неделю.

Читайте также:  Выгодная ипотека — как выбрать самую дешевую ипотеку + профессиональная помощь в получении выгодной ипотеки

Отдельное спасибо Артём за то, что дал ссылку на выполненный конкурентами аналогичный стартап. Теперь будет проще оценить его эффективность и целесообразность вложений…

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

1) МВП можно сделать в компании, а доработки отдать на фриланс. Так получится дешевле, при ряде условий. 2) Желательно чтобы аналитик таки был. Начать желательно с вменяемого ТЗ. 3) Я считаю что для начала надо написать ТЗ, потом нарисовать концепт, сверстать на коленке, и уже оттуда будет видно что надо делать с бекэндом. 4) прототип как вы его себе видите 5) нужно начать с брифа. дальше разбить задачи на шаги, и давать на реализацию по шагам. К примеру, создать бриф, создать ТЗ, нарисовать прототипы, нарисовать первичный дизайн, заверстать, ну и т.д.

На каждом этапе поручать стороннему специалисту провести аудит. Можно вообще нанять QA, с которым и оговорить аудит каждого шага.

Нравится 1 Комментировать

Источник: https://toster.ru/q/395059

Запуск ИТ-проекта без инвестиций — история создания RentacarFor.Me

Создатель сервиса RentacarFor.Me Кирилл Антошин в колонке для vc.ru проанализировал собственный опыт запуска ИТ-проекта и составил свод рекомендаций для начинающих предпринимателей. Автор рассказал, как подбирал команду, отлаживал рабочие процессы и читал письма, адресованные службе поддержки.

Когда я рассказываю, что команда моего проекта — это пять-семь человек, живущих в разных концах планеты, люди сразу делают такое лицо, мол: «Да-да, конечно, заливай!» Но серьезно — RentacarFor.me начинался с трех человек: меня, программиста и дизайнера. Не было никаких питчей, лифтов, пивотов и прочей стартаперской ерунды.

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

Прибыль

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

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

Запомните: никто никогда не будет платить за красоту и удобство, все будут платить за доступность, хорошее качество, за что угодно, дающее реальную пользу, а не просто красивую картинку. Это многократно доказано.

Планирование

Постоянное планирование и бюджетирование — это очень важно для бизнеса. Каждый менеджер должен уметь работать с Excel. Лучше и доступнее для управления финансами пока ничего не придумали.

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

Если планируете привлекать кредитные средства, то делайте это только если на 100% уверены, что кредит будет погашен.

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

Команда

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

  1. Разработчик должен уметь писать тексты. По структуре изложения мыслей вы сможете понять, логично ли размышляет человек. А для ИТ-специалиста логика стоит на первом месте.
  2. У него должны быть публичные open-source проекты. Наличие таких проектов показывает, что человек воспринимает свою работу не как ремесло, а как творчество. А разработка программного продукта это чистой воды творчество.
  3. Он должен работать в OS X. Это личное наблюдение: если человек работает на компьютере Apple, значит, он ценит красоту. Красоту визуальную, красоту в работе и красоту в образе жизни. У такого человека и код будет стройный и красивый.
  4. Разработчик должен жить в Белоруссии. Это не дискриминация, просто в Белоруссии в стартап-тусовке все спокойнее, нет безумных денег, нет скороспелых проектов. Поэтому культура работы в ИТ-отрасли, на мой взгляд, выше. В России (даже в регионах) за простое мобильное приложение мне не ставили ценник меньше €10 тысяч. В Белоруссии делают за €6 тысяч, а если стажер будет писать код под присмотром, то €4,5 тысячи.

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

Процессы и сервисы

Источник: https://vc.ru/13650-antoshin-startup

Хочется побыть крутым начальником? Не идите в стартап | Rusbase

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

Я расскажу, как выглядит работа СТО и co-founder’а изнутри. Надеюсь, кому-то из молодых технических директоров мой опыт поможет не совершить старых ошибок — ведь грабли, на которые наступают люди с техническим складом ума, обычно весьма похожи.

Личное дело: нужен ли программисту стартап

Итак, прежде чем запускать собственный стартап, в первую очередь, стоит вспомнить о систематической ошибке выжившего — survivorship bias. Суть survivorship bias заключается в том, что мы получаем много информации о группе «выживших» и почти никакой информации — о «погибших». В

Когда мы в 2015 году попали в акселератор TechStars Berlin, нам на первой же презентации привели статистику по проблемам, о которых не пишут специализированные СМИ. Стартап может столкнуться с депрессией или семейными проблемами фаундеров, тюремным заключением, алкоголизмом и кучей других сложностей. Все ситуации — реальные случаи, и это только малая часть.

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

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

Начало работы: как принять правильные решения на старте

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

На этом этапе часто возникает вопрос или даже дискуссия: писать ли проект на том, что уже знаешь, или взяться за новую технологию? Конечно, первый вариант быстрее, зато второй — интереснее с точки зрения профессионального роста. Мне приходилось работать в обоих вариантах (в свое время осваивал Groovy в таких условиях).

Но «интересно» — не тот параметр, который решает все. Чтобы построить успешный бизнес, логичнее спросить себя:

  • Смогу ли я на той технологии, которой уже владею, построить архитектуру для масштабируемого проекта?
  • Смогу ли я на этапе роста стартапа, нагрузок и команды оптимизировать, переписать или эффективно поддерживать проект на этой технологии?

В нашем случае основной проект на Python дополнялся функционалом на Java, JS. Коммуникации с основным проектом осуществлялись через RabbitMQ. К слову, рекомендую книгу Сэма Ньюмана о построении микросервисов, можно бесплатно получить по ссылке.

С самого начала важно взять хороший фреймворк под свой язык программирования, ибо при написании проекта с нуля набор задач в целом похож, и большую часть из них уже решили. Scaffolding, сообщество разработчиков, хороший набор библиотек (желательно с большим количеством звезд на GitHub) — вот те вещи, на которые стоит обращать самое пристальное внимание.

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

Релиз MVP и выбор фич проекта

На начальном этапе главная задача — релиз MVP. Советую быстро писать хороший код и при этом не забывать о коммуникации с коллегами, отвечающими за бизнес-составляющую проекта. Очень важно, чтобы бизнес-часть команды занималась «продажами» еще до релиза.

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

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

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

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

По опыту могу сказать, что затягивание сроков — негативный сценарий. Если не получается уложиться, лучше, как говорится, флексить скуп фичи — изменить объем функционала так, чтобы не выбиваться из графика. Все, что не успеется до дедлайна, переносится в следующую итерацию разработки.

При этом от накопления «технического долга» все равно никуда не денешься. Но нужно следить, чтобы на начальных этапах не было критических ошибок в архитектуре. Рекомендую общаться с хорошо подкованным ментором или поддерживать связь с СТО других проектов, которые уже прошли данный этап и могут дать совет.

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

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

Этап роста: что нужно и чего не нужно делать разработчикам

Как только вашим продуктом начнет пользоваться постоянно растущая аудитория, обязательно возникнет вопрос о том, способен ли проект выдерживать растущие нагрузки. Вспомним слова Дональда Кнута: «Premature optimization is the root of all evil». Нужно дважды подумать, существует ли для вас подобная проблема.

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

Читайте также:  5 главных принципов успешного проведения swot-анализа

Вот примеры задач, которыми не должны заниматься девелоперы:

  • Локализация продукта. Стартапы из СНГ в большинстве случаев «обречены» выходить на глобальный рынок, потому что делать продукты исключительно для локального рынка экономически нецелесообразно. И я часто замечал, что коллеги из других проектов регулярно просят изменить какой-то текст, потому что нашлась ошибка локализации или были загружены новые тексты на сайт. Базовая имплементация continuous localization — вот что нужно, чтобы больше никогда не тратить время программистов на рутинные задачи по обновлению переводов.
  • Поддержка пользователей. Да, на первых порах приходится заниматься этим самостоятельно, но когда количество обращений все растет и растет, приходит время набирать команду в саппорт. В нашем случае именно специалист отдела поддержки был первым человеком, который присоединился к команде, и это оказалось одним из наиболее верных кадровых решений. Хочу уточнить, что поддержкой все равно придется заниматься, за все баги будете отвечать вы, но можно будет забыть хотя бы о рутинных задачах — вроде выяснения версии браузера или предложения почистить cookies.
  • Маркетинг.

Источник: https://rb.ru/opinion/krutoy-boss/

IT бизнес с нуля: идеи, бизнес план ИТ компании

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

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

Как начать IT бизнес с нуля? Какие перспективные направления для данного рынка существуют сегодня и какие сложности могут подстерегать начинающую ИТ-компанию? Узнаем на примере бизнес-плана.

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

Если вы хотите узнать, как решить именно Вашу проблему — обращайтесь в форму онлайн-консультанта слева или звоните по телефону +7 . Это быстро и !

Форма бизнеса

С чего начать создание ИТ-компании? Прежде всего, специалисты рекомендуют выбрать подходящую форму бизнеса. Дело в том, что начиная предпринимательскую деятельность, любой человек вынужден пересматривать свои профессиональные компетенции.

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

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

С чего начать? Существуют следующие варианты:

  • Фриланс;
  • ИТ-консалтинг;
  • ИТ-компания.

Рассмотрим более подробно каждый из вариантов.

Фриланс

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

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

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

ИТ-консалтинг

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

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

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

В чем заключаются стандартные услуги ИТ-консультанта:

  • Повышение эффективности ИТ-проекта компании;
  • Оптимизация расходов на установку и поддержку ИТ-технологий;
  • Поиск возможных проблем и помощь в их устранении;
  • Решение вопросов о необходимости привлечения дополнительных ИТ-ресурсов;
  • Решение вопроса эффективности штатных ИТ-сотрудников.

Такая форма ведения бизнеса, как и фриланс, требует лишь оформления ИП для легализации работы с заказчиком.

Пример создания и продвижения онлайн сети ИТ-консультантов можете увидеть в данном видео.

ИТ-компания

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

Также создание ИТ-компании в большинстве случаев требует наличия инвестора или партнеров для разделения затрат.

Бизнес-план ИТ-проекта должен ориентироваться на те цели, которые ставит перед собой будущая компания:

  1. Сервисный бизнес – техническое обслуживание ИТ-процессов компании заказчика;
  2. Аутсорсинговый бизнес – частичная ли полная поддержка ИТ-технологий компании. Заказчик в данном случае отказывается от штатных ИТ-специалистов и делегирует все задачи по техническому и информационному обслуживанию технологий аутсорсингу;
  3. Создание стартапа или компании-разработчика, итоговой целью которой становится готовый инновационный продукт.

Важные моменты в создании IT-компании можно узнать из видео ролика ниже.

Идея

Это едва ли не главная составляющая ИТ-бизнеса. Создание фирмы по техническому обслуживанию компьютеров – это еще не идея. Разновидностей услуг в данной сфере – великое множество, поэтому необходимо иметь представление о конечном продукте компании. Полезно составить пробную версию перечня услуг.

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

Так, Алекс Тью, миллионер из США, некогда предложил желающим покупать пиксели его сайта, по цене 1 доллар за штуку. Последний пиксель был продан с аукциона по цене более 38 тысяч долларов США.

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

Регистрация

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

Помещение

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

Сегодня все чаще организации предпочитают не строить или приобретать помещение, а арендовать офис.

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

Оборудование

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

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

Услуги

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

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

Продвижение

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

Расходы и окупаемость

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

Срок окупаемости – это время, в течение которого фирма начинает приносить прибыль.

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

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

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

В заключение

Бизнес-план ИТ-компании – это не просто формальность. Данные рекомендациями помогут будущему стартаперу трезво оценить свои возможности и рассчитать целесообразность затрат. Бизнес-план помогает оформить бизнес-идею, привести ее к законченной форме продукта для потребителя. К тому же, грамотно составленный бизнес-проект обязательно обратит на себя внимание инвестора.

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

Источник: https://vashbiznesplan.ru/internet/biznes-v-it.html

Как запустить стартап, если вы не умеете программировать

Для тех, кто дума­ет над запус­ком стар­та­па, но не име­ет ника­ких тех­ни­че­ских навы­ков, осно­ва­тель Ecquire Таль Равив (Tal Raviv) напи­сал ста­тью о том, как запу­стить стар­тап без про­грам­ми­ро­ва­ния.

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

Ищи­те ли вы в таком слу­чае парт­не­ра, кото­рый обла­да­ет необ­хо­ди­мы­ми тех­ни­че­ски­ми навы­ка­ми, или сами учи­тесь про­грам­ми­ро­ва­нию – рас­про­стра­нен­ным явля­ет­ся мне­ние, что чело­век, кото­рый не уме­ет коди­ро­вать, – это не более, чем кто-то с гото­вой пре­зен­та­ци­ей Powerpoint.

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

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

Как им это уда­ет­ся?

Фокус на обслуживании клиентов вместо создания продукта

Успеш­ные пред­при­ни­ма­те­ли зна­ют одно пра­ви­ло: важ­нее поза­бо­тить­ся о кли­ен­те, чем создать про­дукт.

Мно­гие же так увле­ка­ют­ся созда­ни­ем про­дук­та, что забы­ва­ют о глав­ной зада­че – решить про­бле­му кли­ен­та (кото­ро­му, в общем-то, все рав­но, каким спо­со­бом вы это сде­ла­е­те).

Люди, а не технологии

Поду­май­те о самой слож­ной части ваше­го биз­не­са – может ли чело­век реа­ли­зо­вать ее сво­и­ми сила­ми?

Для мно­гих стар­та­пов это было клю­чом к успе­ху.

Напри­мер, Дэвид Куа­ил (David Quail), раз­ра­бот­чик про­грамм­но­го обес­пе­че­ния, хотел най­ти реше­ние для одной раз­дра­жа­ю­щей его вещи – пла­ни­ро­ва­нию встреч по email.

Иде­ей Дэви­да было создать искус­ствен­ный интел­лект, кото­рый мог бы читать элек­трон­ные пись­ма и авто­ма­ти­че­ски пла­ни­ро­вать собы­тия. Но созда­ние тако­го инстру­мен­та заня­ло бы меся­цы, если не годы.

Что Дэвид сде­лал, что­бы начать про­ект как мож­но ско­рее? Он про­сто создал email адрес для сво­их кли­ен­тов, копии писем кото­рых пере­сы­ла­лись ему, и сна­ча­ла делал всю рабо­ту вруч­ную, что­бы понять, насколь­ко нужен такой сер­вис и гото­вы ли кли­ен­ты за него пла­тить.

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

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

Используйте уже готовые инструменты

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

  • Исполь­зуй­те гото­вые сер­ви­сы для при­е­ма элек­трон­ных пла­те­жей;
  • Созда­вай­те интер­ак­тив­ные фор­мы на сай­те, с помо­щью кото­рых кли­ен­ты смо­гут общать­ся с вами;
  • Созда­вай­те базы зна­ний и фору­мы с помо­щью таких инстру­мен­тов, как Zendesk, Uservoice или GetSatisfaction;
  • Исполь­зуй­те гото­вые видже­ты и кноп­ки – Skype, чат и т.д.;
  • Исполь­зуй­те про­стые плат­фор­мы для созда­ния сай­та – WordPress, Strikingly, Unbounce.
Читайте также:  Скорая финансовая помощь: 5 ситуаций, когда нужно заблокировать банковскую карту

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

WordPress

Для боль­шин­ства WordPress ассо­ци­и­ру­ет­ся с бес­плат­ны­ми бло­га­ми и про­стым созда­ни­ем сай­тов. Но глав­ная магия WordPress заклю­ча­ет­ся в воз­мож­но­сти рас­ши­ре­ния функ­ци­о­на­ла и созда­ния прак­ти­че­ски любо­го типа сай­та – и для это­го вам по-преж­не­му не нуж­но учить­ся про­грам­ми­ро­вать.

Вме­сто того, что­бы тра­тить мно­го денег на дизай­не­ра, вы може­те купить тему за $40 и настро­ить ее так, как хоти­те. WordPress явля­ет­ся одним из луч­ших инстру­мен­тов для созда­ния сай­тов без навы­ков про­грам­ми­ро­ва­ния. Во вся­ком слу­чае, научить­ся им поль­зо­вать­ся – намно­го про­ще и быст­рее, чем най­ти раз­ра­бот­чи­ка или само­му научить­ся писать код.

Соберите все вместе

Вер­ни­тесь к глав­но­му вопро­су – что нуж­но вашим кли­ен­там? – и поду­май­те над тем, как вы може­те им это дать. Шан­сы, что вы смо­же­те сде­лать все само­сто­я­тель­но, высо­ки. Если нет, то рас­смот­ри­те более скром­ное нача­ло – зато вы смо­же­те сра­зу полу­чать при­быль и финан­си­ро­вать даль­ней­шее раз­ви­тие.

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

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

Источник: https://te-st.ru/2013/12/03/how-to-launch-a-startup-without-writing-code/

Стоит ли бизнес кофаундеру IT-стартапа учиться программировать?

Далеким летом 2014 года мой ответ на этот вопрос был утвердительным. Это точно изменило мою жизнь. А вот в какую сторону — вопрос открытый.

В любом случае я с радостью (и болью) делюсь выстраданными и вычитанными мыслями и личным опытом.

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

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

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

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

Моя история

В 2014 году наша команда из 4 человек (4 кофаундера, из которых только один был разработчиком) работала над сайтом для подготовки к ЕГЭ bitclass.ru.

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

Эта история еще не закончилась, и о том, что получилось в результате, я еще напишу (получилась lampa.io — социальная образовательная платформа, где публиковать учебные материалы может не только наша редакция, но и все желающие).

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

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

Потом я выбрала самый интенсивный и хардкорный курс по JavaScript + Node.js, который смогла найти, и с головой погрузилась в программирование на 3-3.5 месяца.

Это было замечательное время, и программировать почти без выходных (официально 6 дней в неделю по 11 часов в день + еще часов 3-5 после занятий), с перерывами только на сон и еду, в компании людей, которые проходят через тот же опыт, было очень здорово. С одной стороны, мы много работали.

С другой стороны, после года работы над собственно стартапом, в котором основной трудностью была постоянная неопределенность, такая структурированная жизнь воспринималось как отпуск. 80-90% моих соучеников стали работать программистами, причем даже не junior’ами.

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

Плюсы и минусы

Начнем с плюсов:

  1. Ваш стартап станет непотопляемым — в самом крайнем и худшем случае ваш burn rate (сумма денег, которую стартап тратит за определенный период времени) может стать равным тратам на жизнь одного человека (в этом, впрочем, есть и минус — можно заниматься бесперспективным проектом годами и потратить на это лучшее время жизни); даже если ваша команда почему-то развалится, стартап сможет это пережить.
  2. На старте вы можете двигаться быстрее, если в команде появляется еще один программист; хотя с учетом вашей неопытности за полноценную боевую единицу вас поначалу считать будет нельзя; на более поздних стадиях это не имеет большого значения, потому что вы сможете найти еще одного или нескольких программистов на зарплату.
  3. Не будет мучительного периода, когда продукт еще не готов, а остальным членам команды вроде бы нечего делать. Что приводит к сомнениям, брожению умов и депрессивным настроениям. Главное – помните: то, что вам нечего делать, – полнейшая иллюзия и оправдание своей лени или неуверенности.
  4. Это, пожалуй, самый главный плюс: даже как бизнес-кофаундер, выполняя вполне себе бизнес-функции, вы становитесь намного более эффективными. Есть тысяча мелочей, для быстрого выполнения которых нужны технические навыки: быстрая публикация нового контента на сайте, добавление JavaScript целей в Яндекс-Метрике, выгрузка данных из базы, тестирование нового value proposition на лендинге. Каждое из этих действий – это даже не программирование, иногда это пара строчек кода, но без технических навыков самостоятельно с ними не справиться. Надо хотя бы знать, куда залезть, чтобы эту пару строчек кода написать. А значит, без технических навыков вы будете двигаться медленнее, чем могли бы.
  5. Вы сможете оценить, сколько времени занимает какая работа, а значит, сможете лучше планировать и приоритизировать разные задачи. До своего погружения в программирование иногда я даже не высказывала какие-то предложения, заранее предполагая, что делать это долго и сложно, хотя на самом деле их внедрение заняло бы от силы час.
  6. Когда заканчиваются аргументы, можно быстро что-то сделать самому. Да, в команде должен быть консенсус, но если вы очень верите в какую-то фичу, а кофаундера убедить никак не можете, в крайнем случае можно быстро ее внедрить и проверить результат. А если не пойдет – без проблем убрать.

Но минусы перевешивают:

  1. Начнем с очевидного. За то время, которое нужно, чтобы по-настоящему научиться программировать, можно сделать много всего полезного. Об этом ниже. В самом крайнем случае можно заработать денег, которые пойдут на зарплату недостающего программиста.
  2. Желание научиться программировать, то есть все делать самому, может быть признаком неумения или нежелания делегировать и мотивировать или неуверенности в идее.
  3. У вас появляется дополнительный стимул к тому, чтобы работать много, вместо того, чтобы работать с умом (привычнее в формулировке work hard, not smart). Если считать, что мать изобретений – необходимость, то у ваших потенциальных изобретений будет меньше шансов родиться. У вас больше не будет необходимости придумывать быстрые эксперименты. Зачем делать что-то быстрое и сырое, если можно сразу сделать красиво и правильно? Кстати, такая же ловушка подстерегает и те команды, где все фаундеры изначально программисты.
  4. Если программировать вам понравится (а это кажется необходимым условием для того, чтобы это вообще получалось), то вам захочется программировать все время; все остальные направления деятельности стартапа, например customer development или маркетинг, будут от этого сильно страдать; программировать очень приятно психологически: вы создаете продукт, в конце дня появляется осязаемый результат и при этом никто вам не говорит, что-то, что вы сделали, абсолютно никому не нужно. Если же вы общаетесь с потенциальными пользователями или даже просто исследуете рынок, то с большой вероятностью постоянно получаете плохие новости.
  5. Понимание технической стороны вопроса ограничивает полет вашей фантазии. Если вы знаете, что какую-то фичу предстоит внедрять вам, то вы с большой вероятностью придумаете какой-то ее вариант, который проще в разработке, а не лучше для пользователей. И это не всегда эффективно: да, вы потратите на разработку на день меньше, но потеря, например, конверсии за счет неоптимального для пользователей решения может перекрыть всю экономию времени.

Чем себя занять

Так что же делать нетехническим фаундерам в смутное время, когда MVP не готов? Вариантов множество, а некоторые дела и просто лежат на вашем «критическом пути».

  • Совершенно очевидно, что можно работать над разными параллельными разработке задачами. В нашем проекте как раз с этим все было просто. Так как продукт состоит из технологии и контента, логично было заниматься созданием контента.
  • Во многих случаях customer development можно начинать до появления MVP. Можно проводить интервью с целевой аудиторией не для того, чтобы дать им попробовать ваш продукт, а чтобы понять, чем живут ваши пользователи, как этот рынок работает сейчас без вас и какие у пользователей проблемы (почти точно в этом месте я цитирую чей-то чужой пересказ книги Lean Startup). Интервью должно быть много. И их результаты должны определять, что же, собственно, вы разрабатываете, или хотя бы влиять на это.
  • Можно сделать прототип основных интерфейсов (в идеале “живой” — с активными зонами) и заниматься его тестированием c потенциальными пользователями. Плюсы от этого шага кажутся очевидными, но почему-то на своих проектах мы упорно этого не делаем. Подозреваю, что такую же ошибку допускают и другие команды, в которых нет дизайнера. Важно создать и протестировать прототип не столько потому, что так вы сразу улучшаете usability, сколько ради того, чтобы лучше продумать весь продукт от начала до конца, а также лишний раз пообщаться с пользователями и оценить их реакцию на то, что вы делаете.
  • Можно проверять, насколько ваша идея интересна целевой аудитории, рассказывая о ней в тематических пабликах в социальных сетях. Можно начинать вести свой блог. Так вы можете нарастить аудиторию еще до запуска продукта. А если вас никто не читает, встает вопрос о том, нужно ли кому-то то, что вы делаете.

Резюме

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

Источник: http://www.pvsm.ru/opy-t/241927

Ссылка на основную публикацию