Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 122
я вот не пойму он вам друг? или быдло?
если и то и то то тогда кто вы?
если и то и то то тогда кто вы?
Дружба и бизнес разные вещи.
Я считаю: Быдло бизнесмен — это не характер персоны, а ее характеристика поведения с точки зрения бизнеса. Т.е. может человек он и не плохой, а бизнес ведет как «быдло». Нужно называть вещи своими именами, и я не думаю, что это весомое оскорбление, ведь характеризовалась не персона, а «стиль» ведения бизнеса. Хотя все эти вещи довольно относительны.
ТО есть вы верите в то что люди меняются? То есть стиль бизнеса отличен от стиля жизни? В таком случае действительно пора закрывать лавочку.
Меняется всё, что вы видите вокруг. В том числе и люди. Если человек не опытен или глуп, и ведет такой «стиль» бизнеса, это не значит что он моральный урод, вы не считаете?
Деньги меняют людей. Часто в худшую сторону. Да, и в процессе зарабатывания денег все могут для кого-то быть моральными уродами. Все относительно
Я не склонен считать незнакомого мне человека моральным уродом или давать ему какие-либо оценки.
Более того я не знаю что это за стиль ведения бизнеса «быдло-стиль» я знаю стили «в лоб», «напролом» и т.д. — но они не несут в себе эмоциональной окраски.
Насчёт того что меняется всё вокруг — я согласен, но люди остаются прежние. Есть даже такая поговорка — вы через 10 лет — это тот же вы + люди с которыми вы общались + книги, которые вы прочитали.
Бурную дискуссию касательно моего комментария возможно стоит завершить. Мне показалось необычным, даже несколько неприятным словосочетание «друг — быдло-бизнесмен». Но оно имеет право на жизнь как и любое другое. Своей точки зрения я никому не навязываю.
Более того я не знаю что это за стиль ведения бизнеса «быдло-стиль» я знаю стили «в лоб», «напролом» и т.д. — но они не несут в себе эмоциональной окраски.
Насчёт того что меняется всё вокруг — я согласен, но люди остаются прежние. Есть даже такая поговорка — вы через 10 лет — это тот же вы + люди с которыми вы общались + книги, которые вы прочитали.
Бурную дискуссию касательно моего комментария возможно стоит завершить. Мне показалось необычным, даже несколько неприятным словосочетание «друг — быдло-бизнесмен». Но оно имеет право на жизнь как и любое другое. Своей точки зрения я никому не навязываю.
Может ваш друг понимает, что крупный проект его команда не потянет и ее нужно натаскать на мелких проектах?
Я думаю, что нужно ставить на поток те проекты, которые команда может гарантированно выполнить в установленные сроки.
И затем нужно сложность проектов постепенно увеличивать — не сразу браться за рублевые проекты, а потренироваться на 10, 20, 50 копеечных…
Я думаю, что нужно ставить на поток те проекты, которые команда может гарантированно выполнить в установленные сроки.
И затем нужно сложность проектов постепенно увеличивать — не сразу браться за рублевые проекты, а потренироваться на 10, 20, 50 копеечных…
«я утверждаю, что лучше продать большое количество предметов производства с маленькой прибылью, чем малое количество с большой.» — Генри Форд
Как говорит мой друг, бывший телемастер — Лучше отремонтировать один телевизор за тысячу рублей, чем десять за сто.
Риск потерять одного клиента выше чем десятерых. Все смотрят с одной точки зрения — как проще заработать. А поставьте вопрос — что лучше когда от тебя уйдет один клиент за 1000 рублей, или два по 100 рублей?
Попытка обрабатывать много маленьких клиентов есть ничто иное как диверсификация рисков! И это просто другая стратегия. Это и правильно и не правильно. В жизни вообще нет ничего правильного или не правильного — есть эффективно или неэффективно.
Попытка обрабатывать много маленьких клиентов есть ничто иное как диверсификация рисков! И это просто другая стратегия. Это и правильно и не правильно. В жизни вообще нет ничего правильного или не правильного — есть эффективно или неэффективно.
Дело не только в прибыли, выраженной материально. Дело еще в интересе и вовлеченности разработчиков в проект. В статье как-то в сколзь об этом говорится.
Если сотрудник делает проекты по «два на день», то он их будет делать по принципу «сделал и забыл». Он будет уверен, что вот конкретно эти строчки кода ни он, да и никто другой, никогда в жизни не увидят, никто не будет его рефакторить и совершенствовать. Поэтому он позволяет себе лениться и писать плохой код.
Однако, если проект сложный и объемный, на его реализацию тратятся месяцы, а то и годы, то сотрудник будет чувствовать что он вкладывает в этот проект что-то еще помимо тысяч строк кода. Он будет вкладывать туда часть себя, потому что он будет думать как и что можно улучшить, как сделать так, чтобы это работало правильно во всех ситуациях и т.д. не только на работе, но и в дороге и иногда дома. Вот тут он уже будет задумываться об архитектуре, правилах именования, паттернах и всем остальном, что присуще только крупным проектам. И что самое удивительное, он будет сам безо всякого давления им следовать, потому что это будет выгодно ему в первую очередь.
Во втором случае у сотрудника появляется возможность сказать «в этот проект вложен год моей жизни — я не позволю ему загнуться!», чего нельзя сказать о проекте, на который он потратил месяц.
Если сотрудник делает проекты по «два на день», то он их будет делать по принципу «сделал и забыл». Он будет уверен, что вот конкретно эти строчки кода ни он, да и никто другой, никогда в жизни не увидят, никто не будет его рефакторить и совершенствовать. Поэтому он позволяет себе лениться и писать плохой код.
Однако, если проект сложный и объемный, на его реализацию тратятся месяцы, а то и годы, то сотрудник будет чувствовать что он вкладывает в этот проект что-то еще помимо тысяч строк кода. Он будет вкладывать туда часть себя, потому что он будет думать как и что можно улучшить, как сделать так, чтобы это работало правильно во всех ситуациях и т.д. не только на работе, но и в дороге и иногда дома. Вот тут он уже будет задумываться об архитектуре, правилах именования, паттернах и всем остальном, что присуще только крупным проектам. И что самое удивительное, он будет сам безо всякого давления им следовать, потому что это будет выгодно ему в первую очередь.
Во втором случае у сотрудника появляется возможность сказать «в этот проект вложен год моей жизни — я не позволю ему загнуться!», чего нельзя сказать о проекте, на который он потратил месяц.
Есть одна проблема.
В моем случае было так: у компании кончились средства на проект, а дополнительных инвестиций не нашли. Текущие договоры не покрыли ЗП сотрудникам, в итоге через несколько месяцев оттуда ушли почти все толковые программисты. Текущее состояние этой компании мне неизвестно, но, судя по всему, ничем хорошим они не кончили.
Так что без адекватного материального резерва или инвестиций браться за большие проекты — самоубийство.
В моем случае было так: у компании кончились средства на проект, а дополнительных инвестиций не нашли. Текущие договоры не покрыли ЗП сотрудникам, в итоге через несколько месяцев оттуда ушли почти все толковые программисты. Текущее состояние этой компании мне неизвестно, но, судя по всему, ничем хорошим они не кончили.
Так что без адекватного материального резерва или инвестиций браться за большие проекты — самоубийство.
Можно было дать каждому программеру долю в компании в обмен на их лояльность и инвестиции их ЗП в этот проект.
это не выход, не каждый бы согласился — деньги-то нужны всегда, а реальность получения дивидентов весьма призрачна
образно говоря, на долю в компании, у которой нету средств, хлеба в магазине не купишь
образно говоря, на долю в компании, у которой нету средств, хлеба в магазине не купишь
Реальность получения дивидентов лежит полностью на вас. Вы будете кровно заинтересованы в получении прибыли.
Ну, или можете уйти на другую работу.
Ну, или можете уйти на другую работу.
как раз не полностью
являясь программистом я могу быть отвественным только за техническую сторону проекта
и что толку, если технически проект будет реализован хорошо, но из-за маркетинка он окажется провальным?
с другой стороны, если дать каждому программисту долю в компании и позволить влиять на принятие решений — вряд ли получится что-то хорошее
являясь программистом я могу быть отвественным только за техническую сторону проекта
и что толку, если технически проект будет реализован хорошо, но из-за маркетинка он окажется провальным?
с другой стороны, если дать каждому программисту долю в компании и позволить влиять на принятие решений — вряд ли получится что-то хорошее
Принятие решения не такая уж страшная штука, как ее все рисуют. Тот, кто уходит от ответственности никогдане возьмет долю в компании. Не забываем, это не только инвестиции, но и обязательства.
Тот, кто готов и имеет возможность рискнуть (или как вы говорите — взять на себя ответственность) — тот идет и открывает свою фирму. Я знаю много отличных программистов, ответственных людей, которым очень важно иметь стабильный доход (молодая семья, маленький ребенок, или родители на содержании).
Открывает фирму и прогорает. Потому что хорошесть как программист не повод считаться хорошим бизнесменом
Тут я с вами полностью соглашусь, частенько бывает фейл.
В своем предыдущем комментарии я хотел сказать, что далеко не во всякой ситуации и не всякому человеку будет интересна доля в бизнесе.
Типичный пример — у человека семья, маленький ребенок и/или ипотека, в общем, потребность в стабильном (пусть и относительно небольшом) доходе. И вот наступили тяжелые для компании времена, впереди маячит нестабильная финансовая ситуация (пусть даже с очень вероятным крупным финансовым успехом в конце) — такому человеку важнее иметь рубль завтра и возможность вернуться к семье после 6 вечера, чем 10 рублей после 2 лет полной выкладки.
Бывает другая ситуация, что молодой специалист хочет роста, причем, амбиции идут куда дальше, чем зарплата senior developer'а. Что ж, такой человек заинтересуется долевым участием в бизнесе.
По моему опыту, 1-я ситуация встречается чаще, чем 2-я. И к чему я это говорю? К тому, что пропагандируемое вами решение: предлагать программистам долю в компании в случае серьезных передряг — может и не сработать.
В своем предыдущем комментарии я хотел сказать, что далеко не во всякой ситуации и не всякому человеку будет интересна доля в бизнесе.
Типичный пример — у человека семья, маленький ребенок и/или ипотека, в общем, потребность в стабильном (пусть и относительно небольшом) доходе. И вот наступили тяжелые для компании времена, впереди маячит нестабильная финансовая ситуация (пусть даже с очень вероятным крупным финансовым успехом в конце) — такому человеку важнее иметь рубль завтра и возможность вернуться к семье после 6 вечера, чем 10 рублей после 2 лет полной выкладки.
Бывает другая ситуация, что молодой специалист хочет роста, причем, амбиции идут куда дальше, чем зарплата senior developer'а. Что ж, такой человек заинтересуется долевым участием в бизнесе.
По моему опыту, 1-я ситуация встречается чаще, чем 2-я. И к чему я это говорю? К тому, что пропагандируемое вами решение: предлагать программистам долю в компании в случае серьезных передряг — может и не сработать.
Реальность получения дивидентов — через полгода, допустим.
А это время надо кормить семью, платить ипотеку (съем жилья) и т.п.
Т.е. вы перекладываете необходимость наличия резерва с компании — на сотрудника (он вынужден параллельно работать на других работах или иметь резерв ресурсов, которые проедает).
А это время надо кормить семью, платить ипотеку (съем жилья) и т.п.
Т.е. вы перекладываете необходимость наличия резерва с компании — на сотрудника (он вынужден параллельно работать на других работах или иметь резерв ресурсов, которые проедает).
Есть и обратная сторона. Когда сотрудник сидит на одном и том же проекте годами, вырабатывается синдром «видеть уже этот проект не могу, каждый день одно и то же». И часто после долгой разработки одного и того же проекта, которому конца и края не видно, просто физически хочется реализовать какой-нибудь небольшой проект с очевидным результатом.
Бывает и обратное: формально проекты одинаковые, но каждый стараешься сделать лучше, чем предыдущий (пускай этого никто и не увидит), но зато есть возможность рефакторить и совершенствовать внутреннюю «начинку» при неизменных «внешних интерфейсах», вплоть до разработки «проектогенератора» :). А в большом проекте требования «релиз должен быть вчера», «этого бага вообще не должно было быть, а ты его уже три дня исправляешь», «у конкурента такая-то фича появилась, у тебя неделя» и т. п. могут быть причиной громождения костыля на костыле, при этом рефакторинг, совершенствование архитектуры, смена платформы и т. п. только в личное время без всякой благодарности (а то и с выражением неудовольствия «лучше бы баги дома правил»).
Со временем понимание этого приходит само собой.
Но в любом случае, пока опыта немного — можно побегать за копейками, а потом потихоньку уровень проектов будет расти с уровнем опыта, главное не забыться и не браться по привычке за копеечные дела.
Но в любом случае, пока опыта немного — можно побегать за копейками, а потом потихоньку уровень проектов будет расти с уровнем опыта, главное не забыться и не браться по привычке за копеечные дела.
Правильно я понял, что основная мысль статьи состоит в том, что: Работать много за малые деньги — плохо. Работать мало за большие деньги — хорошо.
Тогда предлагаю еще одну свежую идею: Не работать — за огромные деньги.
Тогда предлагаю еще одну свежую идею: Не работать — за огромные деньги.
Грамотная статья. Спасибо вам.
Отличная статья, спасибо!
Я бы еще к плюсам больших проектов добавил то, что они, как правило, значительно более живучи и при качественной реализации обеспечат разработчика дополнительными задачами по развитию на неопределенно большое время.
В противовес этому маленькие проекты очень часто умирают, не прожив и нескольких месяцев (проверено на собственном опыте: пытались запустить направление бизнеса по разработке сайтов за… кажется, 15 тыс. рублей. В итоге, из 10-ти разработанных проектов годовщину существования смогли отметить всего 2 или 3).
Я бы еще к плюсам больших проектов добавил то, что они, как правило, значительно более живучи и при качественной реализации обеспечат разработчика дополнительными задачами по развитию на неопределенно большое время.
В противовес этому маленькие проекты очень часто умирают, не прожив и нескольких месяцев (проверено на собственном опыте: пытались запустить направление бизнеса по разработке сайтов за… кажется, 15 тыс. рублей. В итоге, из 10-ти разработанных проектов годовщину существования смогли отметить всего 2 или 3).
А сколько проектов выживает в более высокой ценовой категории? Если есть реальные примеры и цифры — прошу :)
Не нужно мерять количество. Если банк заказывает себе разработку новой АБС, то он будет на 100% уверен в том, что этот проект будет жить. Ведь это артерии любого банка. Заметьте, что в терминологии больших компаний по разработке ПО для корпоративного бизнеса не звучат слова ПО, а звучат слова решения, интеграция, масштабирование. ПО там всего лишь инструмент. Если некое решение использует ПО, то оно будет жить ровно до нового обновления решений. Это может быть и год, и десять лет.
Боюсь, выборка по нашей компании будет не слишком репрезентативной.
Первые версии 2/3 работ в нашем портфолио (http://www.businessreklama.ru/portfolio/by_types/sites/?_page_num=all) были разработаны 2 и более года назад. «Первые», потому что примерно каждый третий из них в разное время достаточно существенно «апгрейдился».
Первые версии 2/3 работ в нашем портфолио (http://www.businessreklama.ru/portfolio/by_types/sites/?_page_num=all) были разработаны 2 и более года назад. «Первые», потому что примерно каждый третий из них в разное время достаточно существенно «апгрейдился».
Если интересно, могу посмотреть статистику по средней «живучести» веб-проектов, размещенных студиями на CMS Magazine, в разрезе их (студий) ценовых сегментов.
Небольшие проекты так же необходимы для поддержания стабильности. Это так называемая стратегия LongTail.
А еще можно не впадать в крайности, и брать как маленькие, так и большие проекты. Большие — для развития, маленькие — для диверсификации и подстраховки.
Это не впадание в крайности. Подумайте над тем, а не проедаете ли вы сейчас свои интеллектуальные ресурсы? И куда вы придете через три года с таким поведением?
В голову почему-то пришло сравнение с кинематографом. Маленькие однотипные проекты сравни дешевым сериалам — все как один, бесконечный сюжет, одни и те же лица, одни и те же декорации.
Крупные проекты, наоборот, сравни блокбастерам, которые захватывают дух, производят неизгладимое впечатление, остаются в памяти на долго.
Но для производства блокбастера надо потратить годы и миллионы, в то время как для создания очередной серии очередного сериала с уже готовыми декорациями и пр. достаточно потратить неделю-две съемок и пару дней редактирования отснятого.
А теперь главный вопрос — какую прибыль принесет блокбастер и какую сериал? Что инетерсней создавать? От какого результата получишь больше удовлетворения? Где используются последние достижения кинемотографии?
Крупные проекты, наоборот, сравни блокбастерам, которые захватывают дух, производят неизгладимое впечатление, остаются в памяти на долго.
Но для производства блокбастера надо потратить годы и миллионы, в то время как для создания очередной серии очередного сериала с уже готовыми декорациями и пр. достаточно потратить неделю-две съемок и пару дней редактирования отснятого.
А теперь главный вопрос — какую прибыль принесет блокбастер и какую сериал? Что инетерсней создавать? От какого результата получишь больше удовлетворения? Где используются последние достижения кинемотографии?
Во многом согласен, но, как водится, случаи бывают разные. Ни одно решение не является 100% всесторонним.
Те же мелкие проекты — если их действительно много, и они однообразные, можно автоматизировать. Или иметь набор типовых решений, как документов, так и компонентов к своему фреймворку. Смею уверить, сделать это действительно непросто, особенно так, чтобы не завязнуть, и по сложности ничуть не уступает иному крупному проекту, как с точки зрения затрат, так и опыта.
Большие проекты, конечно, получше. (тут идет список из xx если). А маленькие, конечно, похуже. (тут идет список еще из yy если).
Те же мелкие проекты — если их действительно много, и они однообразные, можно автоматизировать. Или иметь набор типовых решений, как документов, так и компонентов к своему фреймворку. Смею уверить, сделать это действительно непросто, особенно так, чтобы не завязнуть, и по сложности ничуть не уступает иному крупному проекту, как с точки зрения затрат, так и опыта.
Большие проекты, конечно, получше. (тут идет список из xx если). А маленькие, конечно, похуже. (тут идет список еще из yy если).
1. Разработка одного большого проекта надоест, так как каждый день видеть одно и то же.
2. Риск при одном проекте — очень большой, так как в одночасье можно лишиться всего.
И видимо автору никогда не задерживали зарплату, т.к. у инвестора закончились деньги на проект.
Работал в компании и одним-двумя большими проектами (от одного инвестора) и в компании с небольшими проектами. Сделаю вывод что лучше делать 10 мелких сайтов для клиентов и 2-3 своих проекта, от которых потом получать деньги.
2. Риск при одном проекте — очень большой, так как в одночасье можно лишиться всего.
И видимо автору никогда не задерживали зарплату, т.к. у инвестора закончились деньги на проект.
Работал в компании и одним-двумя большими проектами (от одного инвестора) и в компании с небольшими проектами. Сделаю вывод что лучше делать 10 мелких сайтов для клиентов и 2-3 своих проекта, от которых потом получать деньги.
1. Нет, не надоедает на протяжении трех лет. Потому что задачи всегда разные и одна сложнее другой
2. Это да, я это и записал в минусы.
Автор понимает разницу между инвестированием в будущее и банальным фейлом руководства. Я сам инвестировал своим рабочим временем в наш проект. У меня были запасы, поэтому я спокойно это пережил.
А если кто-то берется за проект не из своей весовой категории, то жди беды
2. Это да, я это и записал в минусы.
Автор понимает разницу между инвестированием в будущее и банальным фейлом руководства. Я сам инвестировал своим рабочим временем в наш проект. У меня были запасы, поэтому я спокойно это пережил.
А если кто-то берется за проект не из своей весовой категории, то жди беды
Вот как раз разработка одного большого проекта не надоест, потому что там как правило сложность решаемых задач повышается, увеличия детализация сервисов, уточняются задачи и четко видно фрагментирование по модулям.
В маленьких же проектах наоборот — задачи в большинсве своем однотипные и постоянно приходится изобретать велосипед или использовать копипаст или аналогичные методики. Это быстро утомляет, ибо это скучно — топчишься на месте, нет времени разрабатывать нормальную архитектуру, потому что горят сроки и надо сделать быстро.
Да, мелкие проекты принесут Вам именно сейчас больше денег, но Вы на это потратите свою жизнь. С чем Вы останетесь через 5 лет, например. Все так же будете писать мелкие проекты?
В маленьких же проектах наоборот — задачи в большинсве своем однотипные и постоянно приходится изобретать велосипед или использовать копипаст или аналогичные методики. Это быстро утомляет, ибо это скучно — топчишься на месте, нет времени разрабатывать нормальную архитектуру, потому что горят сроки и надо сделать быстро.
Да, мелкие проекты принесут Вам именно сейчас больше денег, но Вы на это потратите свою жизнь. С чем Вы останетесь через 5 лет, например. Все так же будете писать мелкие проекты?
Когда я перешел делать маленькие проекты действительно все было однообразно и скучно, копи-паст. Поэтому я решил себя повеселить.
Я выделил наиболее нудные процессы и стал потихоньку их автоматизировать. Через несколько месяцев сайты делались намного быстрее. И еще есть к чему стремиться: к одной кнопке «Сделать пи… то»
Я выделил наиболее нудные процессы и стал потихоньку их автоматизировать. Через несколько месяцев сайты делались намного быстрее. И еще есть к чему стремиться: к одной кнопке «Сделать пи… то»
Всегда стараюсь придерживаться принципа «золотой середины». Данный холивар имеет одно решение: грамотное и аккуратное совмещение обеих стратегий. Любая крайность по-своему опасна.
Какой-то максимализм в этой статье. Расскажите об этом владельцу сети Макдональдс, что ему нужно было строить сеть элитных ресторанов.
Ошибочно считать, что сеть элитных ресторанов является большим проектом по сравнению с Макдональдсом. Это равнозначные по сложности проекты с разным способом ведения бизнеса.
Сначала был один ресторан быстрого питания, в котором выполняли мелкие недорогие заказы, потом он вырос в сеть. Так же и студия может выполнять мелкие недорогие заказы и вырасти в большую сеть студий? Вы-то говорите не о размере компании о величине заказов, причем безапелляционно заявляете. что мелкие заказы — это зло, а большие — добро. На мелких заказах можно построить большой бизнес.
Вы не читаете между строк. Зло не мелкие проекты, а проедание средств без инвестирования.
Если Вы при разработке сотни мелких проектов выработали свою (индивидуальную) технологию, разработали у себя в компании тулзы, которые помогают автоматизировать все или почти все, а потом этот внутренний служебный проект выпускаете под своей собственной маркой, то в этом случае мелкие проекты это добро — они помогают Вам выжить, пока Вы делаете что-то крупное.
Но, если Вы при разработке мелких проектов все делаете однотипно, не пытаетесь переносить наработки между проектами, однотипные фрагменты проектов в лучшем случае копируете (в зудшем пишете заново), то в таком случае мелкие проекты это зло.
Но, если Вы при разработке мелких проектов все делаете однотипно, не пытаетесь переносить наработки между проектами, однотипные фрагменты проектов в лучшем случае копируете (в зудшем пишете заново), то в таком случае мелкие проекты это зло.
Автор теоретик?
Действительно, хотелось бы знать, какую стратегию выбрал автор для управления своей компанией.
Здесь вопрос не только в «управлении своей компанией», а в «управлении своим будущим» с точки зрения простого программиста. Всегда стоит вопрос: «Что выбрать? десяток маленьких проектов за год или делать один проект целый год?». Так вот статья, на мой взгляд, раскрывает именно этот аспект.
Программист получает зарплату, продавая своё время. Задача программиста — искать зарплату повыше, компанию постабильнее, работу поинтереснее, коллег попрофессиональнее и т.п. Какие конкретно факторы важнее и как они кореллируют с подходом «маленькие, но много vs. крупные, но реже» — тема бессмысленного флейма.
Так что статья со всей очевидностью имеет смысл исключительно для тех, кто зарабатывает деньги, делает накопления, нанимает людей и проч.
Так что статья со всей очевидностью имеет смысл исключительно для тех, кто зарабатывает деньги, делает накопления, нанимает людей и проч.
А вот и нет. Программист продает свои знания и умения. Ни один здравомыслящий бизнесмен не будет покупать время программиста. Это невыгодно.
Зарплата повыше может быть, но смысл работы может быть разным. На одной вы будете заняты шахтерством, вот кирка, вот мешок, вот шахта, сколько накопал — все твое. А на другой вы можете заниматься творчеством, постоянно развиваться, тратить свободное время на обучение.
Профессиональность коллег зависит сугубо от сложности проектов, которые решает компания. Найдите профессионалов в начинающей вебстудии.
Да, статья рассчитана на тех, кто хоть раз задумался о своем будущем.
Зарплата повыше может быть, но смысл работы может быть разным. На одной вы будете заняты шахтерством, вот кирка, вот мешок, вот шахта, сколько накопал — все твое. А на другой вы можете заниматься творчеством, постоянно развиваться, тратить свободное время на обучение.
Профессиональность коллег зависит сугубо от сложности проектов, которые решает компания. Найдите профессионалов в начинающей вебстудии.
Да, статья рассчитана на тех, кто хоть раз задумался о своем будущем.
>Найдите профессионалов в начинающей вебстудии.
Полно случаев, когда профессионал(ы) решил(и) перестать работать на дядю и открыл(и) свою фирму. Кстати, на хабре иногда проскакивают мнения, что профессионал должен это сделать, хотя бы попробовать (другое дело, что профессионал, например, в веб-разработке далеко не всегда профессионал в маркетинге или найме таких профессионалов).
Полно случаев, когда профессионал(ы) решил(и) перестать работать на дядю и открыл(и) свою фирму. Кстати, на хабре иногда проскакивают мнения, что профессионал должен это сделать, хотя бы попробовать (другое дело, что профессионал, например, в веб-разработке далеко не всегда профессионал в маркетинге или найме таких профессионалов).
Я, например, выбрал большие проекты, опыт позволяет взять почти любой проект на рынке (точнее, убедить клиента).
Правда, иногда даже выше планки прыгаю (чуть-чуть себе в убыток, на 20-30%).
У больших проектов есть такие плюсы (которые выше я не видел описанными):
+ в процессе разработки можно на пару дней сделать себе отпуск — и этого никто не заметит;
+ нет суеты вокруг с бесконечными «а сделай это, а сделай то»;
И минус:
— в случае форс-мажора иногда придется на работе быть по 40 часов подряд ибо условием получения $150 в час является то, что в случае поломки за сутки терятеся примерно $1500. Мало кто готов подписаться под такими условиями.
А то, что мелкие проекты позволяют заработать больше, чем крупные — это ЛОЖЬ. Если у вас получается меньше — значит вот такая вас весовая_категория/опыт.
Правда, иногда даже выше планки прыгаю (чуть-чуть себе в убыток, на 20-30%).
У больших проектов есть такие плюсы (которые выше я не видел описанными):
+ в процессе разработки можно на пару дней сделать себе отпуск — и этого никто не заметит;
+ нет суеты вокруг с бесконечными «а сделай это, а сделай то»;
И минус:
— в случае форс-мажора иногда придется на работе быть по 40 часов подряд ибо условием получения $150 в час является то, что в случае поломки за сутки терятеся примерно $1500. Мало кто готов подписаться под такими условиями.
А то, что мелкие проекты позволяют заработать больше, чем крупные — это ЛОЖЬ. Если у вас получается меньше — значит вот такая вас весовая_категория/опыт.
Подписываюсь, всё так, и про 40 часов на работе тоже. Правда, был один проект, в котором просто в реальном времени проходило много платежей… и вот он у меня столько нервов съел, что никакими деньгами этого не измерить. )
в процессе разработки можно на пару дней сделать себе отпуск — и этого никто не заметит;Более того я бы даже сказал, что это поможет проекту в конечном итоге, потому что если идет обсуждение и проектирование какого-то важного и сложного фрагмента системы, то информация должна «улежаться» в голове какое-то время, а для этого нужен перерыв. Тогда после перерыва есть возможность взглянуть на вопрос несколько с другой стороны, даже если перерыв был сделан всего на один день.
Практик.
Так расскажите, это же интереснее, чем разжёвывать самоочевидные вещи без конкретных примеров.
И сколько у Вас компаний? Просто как можно делать такие выводы на одном-двух примерах? Есть устоявшиеся маркетинговые стратегии (дифференциации, концентрации, минимизации издержек). Есть методы анализа рынка и сегментов. Есть старый добрый 4P. Нельзя выдергивать из каждого этапа формирования маркетинговой стратегии отдельные куски и говорить, что это самое хорошее. Никто не спорит, что торговать яхтами приятнее, но когда у Вас 1 млн. руб стартового капитала и при этом яхтами торгуют 100 человек, а картошкой один — тут уж выбор очевиден. Или надо было статью позиционировать как посыл к анализу среды. Что прежде, чем браться как все за картошку, посмотрите, может быть яхтами никто не торгует.
Мне кажется, что должен быть симбиоз.
Должны быть и маленькие и большие проекты.
Чтобы уравнять ситуацию.
Должны быть и маленькие и большие проекты.
Чтобы уравнять ситуацию.
Зачем гоняться за тремя копейками, когда к тебе в руки рубль просится? :)
Пока вы даете мелкий проект, ваши ресурсы заняты. А это значит, что вы не сможете сразу приступить к реализации большого проекта, отдав его конкурентам.
Пока вы даете мелкий проект, ваши ресурсы заняты. А это значит, что вы не сможете сразу приступить к реализации большого проекта, отдав его конкурентам.
Я рассматриваю случай, когда есть команда а не один человек.
Я придерживаю мысли (Не стоит держать все яйца в одной кошелке)
Таким образом, риски можно разбросать.
Если не получится выполнить большой проект, или клиент пропадет. Вы останетесь на плаву.
Суммарно, компания все равно останется в выиграше.
Да она получит меньше, ежели бралась только за большие проекты, но она и получит больше если бы она брала одни маленькие.
+ это был бы дополнительный стимул, для сотрудников.
отлично справляешься с мелкими проектами, в качестве вознаграждения получит интересный проект.
Я придерживаю мысли (Не стоит держать все яйца в одной кошелке)
Таким образом, риски можно разбросать.
Если не получится выполнить большой проект, или клиент пропадет. Вы останетесь на плаву.
Суммарно, компания все равно останется в выиграше.
Да она получит меньше, ежели бралась только за большие проекты, но она и получит больше если бы она брала одни маленькие.
+ это был бы дополнительный стимул, для сотрудников.
отлично справляешься с мелкими проектами, в качестве вознаграждения получит интересный проект.
Вставлю свои 5 копеек. Я полагаю, что мелкие проекты найти проще. Взять скажем тот же eLance — непаханое поле для мелких проектов.
А где берут большие? Я был бы рад, что кто-то мне рассказал.
А где берут большие? Я был бы рад, что кто-то мне рассказал.
Большие берутся у больших компаний. Им нужно автоматизировать свои процессы или выходить на другие рынки.
Ну автоматизировать программистов не всегда возможно, а какие пути выхода на рынки?
Есть два пути выхода на более высокий уровень развития.
1. Революционный, например стартап собственного продукта
2. Эволюционный, когда каждый последующий проект дороже предыдущего.
Про первый много рассказывать нечего. Начав выпуск своего продукта весовая категория будет расти сама и автоматически.
Эволюционный путь проходится примерно по такому сценарию. Вы ищете проект, который имеет хоть какую-то перспективу в будущем.
Возьмем, например, такую ситуацию. Вы занимаетесь веб-разработкой, но вашей компании выпал счастливый шанс сделать сайт кинотеатра. Одной из задач — система бронирования билетов. Сначала вы реализуете ее так, как можете. В процессе работы у заказчика будут возникать разные пожелания. Например, помимо самого бронирования появится сервис вип-брони на большее время или лучших мест. Потом появится система скидок, потом система уведомления о новинках, и так далее. Вот он готовый продукт. Вам достаточно оформить его в коробочное решение, и начать продавать. При качественности и успешности продукта ваша слава разработчика ПО пойдет дальше. Возможно, владелец какого-то кинотеатра захочет автоматизировать еще какой-то свой бизнес-процесс, и тогда вы получите еще один заказ и еще один тип продуктов.
И так далее.
1. Революционный, например стартап собственного продукта
2. Эволюционный, когда каждый последующий проект дороже предыдущего.
Про первый много рассказывать нечего. Начав выпуск своего продукта весовая категория будет расти сама и автоматически.
Эволюционный путь проходится примерно по такому сценарию. Вы ищете проект, который имеет хоть какую-то перспективу в будущем.
Возьмем, например, такую ситуацию. Вы занимаетесь веб-разработкой, но вашей компании выпал счастливый шанс сделать сайт кинотеатра. Одной из задач — система бронирования билетов. Сначала вы реализуете ее так, как можете. В процессе работы у заказчика будут возникать разные пожелания. Например, помимо самого бронирования появится сервис вип-брони на большее время или лучших мест. Потом появится система скидок, потом система уведомления о новинках, и так далее. Вот он готовый продукт. Вам достаточно оформить его в коробочное решение, и начать продавать. При качественности и успешности продукта ваша слава разработчика ПО пойдет дальше. Возможно, владелец какого-то кинотеатра захочет автоматизировать еще какой-то свой бизнес-процесс, и тогда вы получите еще один заказ и еще один тип продуктов.
И так далее.
Я понимаю, но если я пишу сайт кинотеатра я часто подписываю NDA, которая мне не разрешает заниматься такими вещами…
При этом Вам никто не мешает заключить контракт с тем же кинотеатром на дальнейшую разработку и развитие этого проекта. А продажами пусть кинотеатр занимается.
Какими именно вещами? Ни один NDA не может запретить вам заниматься коммерческой деятельностью. А если данная бумага противоречит законодательству, то она не имеет юридической силы.
Речь идет о том что я продам код, который уже кому-то продал.
Если код модифицировать, то его можно продавать сколько угодно раз.
Приведу простой пример, в процессе изготовления продукта вы использовали некий фреймворк. По вашей логике вы больше никогда в жизни не сможете продать ни сточки кода, который использует данный фреймворк. Потому что NDA.
А на самом деле у вас купили не код, а готовое решение. Вы можете сделать похожее готовое решение и продавать его.
Приведу простой пример, в процессе изготовления продукта вы использовали некий фреймворк. По вашей логике вы больше никогда в жизни не сможете продать ни сточки кода, который использует данный фреймворк. Потому что NDA.
А на самом деле у вас купили не код, а готовое решение. Вы можете сделать похожее готовое решение и продавать его.
На самом деле тут все зависит от того, что прописано в договоре на разработку. Если там не прописано ничего, то по-умолчанию в законодательстве прописано что исключительгное право на все исходники принадлежит заказчику, а значит если Вы будете использовать наработки одного проекта, чтобы написать свой, который к тому же будет конкурировать с предыдущим проектом, то есть высокий шанс огрести от наших самых гуманных судов в мире.
Тогда нельзя продавать ни одного продукта, который содержит сторонние фреймворки. Ведь вы не можете продавать то, что нельзя продать по условиям лицензий.
Продукт, который выпущен для одного заказчика не может конкурировать с самим собой. Конкуренция возникает между разными продуктами или между разными заказчиками.
Вообще согласен в одном, суд может принять решение совершенно любое.
Продукт, который выпущен для одного заказчика не может конкурировать с самим собой. Конкуренция возникает между разными продуктами или между разными заказчиками.
Вообще согласен в одном, суд может принять решение совершенно любое.
Идеи, алгоритмы, архитектура и т. п. вроде как не являются объектом авторского права, только программа (исходники, бинарники, ресурсы и т. п.). Исходники, да, по дефолту исключительные права у заказчика. Но, согласитесь, сделать клон продукта, который вы уже сделали куда проще, чем сделать продукт абсолютно с нуля (да ещё, скорее всего, он будет лучше исходного, потому что наверняка, особенно если ТЗ изменялось в процессе или появлились дополнительные ТЗ, были мысли «а вон то можно было бы сделать лучше, но придётся весь проект перелопачивать, значит оставим как сделали, а то в сроки не уложимся»).
P.S. Всё изложенное относится к случаю, если вам заказали разработку ПО (например, CMS или набора модулей к ней), а не создание сайта как такового — во втором случае действует ст. 1297 ГК РФ, по которой заказчик по дефолту приобретает право использования, а исключительное право остаётся у вас (а не 1296, на которую вы, похоже, ссылаетесь, хотя и тут есть, имхо, лазейка: если вы сделаете SaaS на базе разработанной программы — право использовать разработанную программу для собственных нужд у вас также по дефолту есть, то что нужды коммерческие никого не волнует — продавать или иным образом монетизировать вы будете услугу и для этого вам нужна программа :) ).
P.S. Всё изложенное относится к случаю, если вам заказали разработку ПО (например, CMS или набора модулей к ней), а не создание сайта как такового — во втором случае действует ст. 1297 ГК РФ, по которой заказчик по дефолту приобретает право использования, а исключительное право остаётся у вас (а не 1296, на которую вы, похоже, ссылаетесь, хотя и тут есть, имхо, лазейка: если вы сделаете SaaS на базе разработанной программы — право использовать разработанную программу для собственных нужд у вас также по дефолту есть, то что нужды коммерческие никого не волнует — продавать или иным образом монетизировать вы будете услугу и для этого вам нужна программа :) ).
вот вы говорите, что надо искать профессионалов. А вы попробуйте их найти! А если найдёте, то будете неприятно удивлены их зарплатными ожиданиями. Так что не надо списывать со счетов мелкий бизнес. Китайские пуховики за 100$ очень часто побеждают американские за 500$.
> Привлекайте профессионалов на проведение мастер-классов и обучение ваших работников.
Вот она, скрытая реклама: )
Вот она, скрытая реклама: )
Очень напомнило настольную экономическую игру «Денежный поток» Р.Кийосаки, там тоже крутишься по «малому кругу» от зарплаты до зарплаты, пока не выйдешь на «большой круг».
Небольшие проекты тоже надо кому-то делать, но на них нельзя останавливаться. Надо расти. Если в портфолио компании со временем проекты всё больше и сложнее, значит компания не стоит на месте — она развивается. А это именно то, чего хотят видеть инвесторы.
P.S. Отличная статья, жаль карму поднять не могу…
P.S. Отличная статья, жаль карму поднять не могу…
Самое интересное, что руководители фирм гоняющиеся за своими 3-мя копейками постоянно находят оправдания для своего бездействия в плане изменения ситуации, приводя примеры таких же Василий Васильевичей из фирмы конкурента, приводят доводы, что «жить-то нам сейчас на что-то надо», но почему-то не понимают, что изменение ситуации не может произойти мгновенно, но это изменение принесёт в будущем значительный доход, прибыль и развитие, а кроме фирмы Василиев Васильевичей есть ещё такие успешные проекты как Google, Parallels, Яндекс и пр., которые тоже не с неба упали, и в которых явно прослеживается именно работа на перспективу и развитие.
Такие конторы долго не существуют. Их обычный жизненный цикл составляет три года.
Ну почему же? Если брать не только вэб-девелоперские конторы (вэб развивается семимильными шагами), а например конторы, клепающие свои пакеты узкого прикладного уровня (скорость развития не такая большая) для других мелких контор, которые не могут позволить себе дорогие зарубежные аналоги, то первые вполне долго могут жить годами.
Посмотрите хотя бы, что творится в области CAD/CAM/CAE для инженерных расчётов сегодня :)
Посмотрите хотя бы, что творится в области CAD/CAM/CAE для инженерных расчётов сегодня :)
Время таких контор неутомимо стремится к закату. Потому что новые способы разработки, железная часть, отсутствие информационного голода и возможности программ создают благоприятную почву для конкуренции.
То, что было невозможно 5 лет назад сейчас ни у кого не вызывает удивления.
То, что было невозможно 5 лет назад сейчас ни у кого не вызывает удивления.
Пожалуй соглашусь. То, что такие конторы существуют с 90-х по сей день — это скорее заслуга некоторой инерции и накопленной доли рынка. Но если ничего не менять, то спад может случиться и за время на порядок меньше времени существования самой конторы. Условия, информационное поле, скорость развития и ещё куча факторов изменились с 90-х, что неумолимо заставляет либо измениться контору, либо уйти с дороги.
Такие конторы долго не существуют. Их обычный жизненный цикл составляет три года.
Статья из цикла — Бизнесмен вел свой небольшой бизнес несколько лет, пришел умный консультант и сказал, что хватит мол мелочевкой заниматься, развиваться, расширятся и выходить на новый уровень пора. Естественно попросил инвестиций! Как инвестиции кончились (читай деньги бинесмена) консультант объявил его никудышным инвестором, непонимающим открывшихся перспектив и свалил искать другого такого же (читай лоха)!
Какая разница большие или маленькие проекты, единственным критерием оценки служит прибыльность и стабильность. Нет ничего зазорного в том чтобы производить и продавать туалетную бумагу вместо того чтобы развивать процессоры. Без нового интель core XXX многие проживут, а вот без туалетной бумаги сомневаюсь!
Какая разница большие или маленькие проекты, единственным критерием оценки служит прибыльность и стабильность. Нет ничего зазорного в том чтобы производить и продавать туалетную бумагу вместо того чтобы развивать процессоры. Без нового интель core XXX многие проживут, а вот без туалетной бумаги сомневаюсь!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стоит ли гоняться за тремя копейками, когда под ногами лежит рубль?