Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>ИМХО шаровара — занятие для тех, кто уже перерос работу на дядю (по крайней мере на русского дядю, с американским дядей все иначе), но еще не дорос до своего дела.
???
Shareware- это маркетинг. Под shareware попадает Microsoft Windows, Semantec Norton Antivirus, и т.д. Хотел бы я быть таким недорослем, как Bill Gates.
*****
MSS>Стать таким бизнесменом, как тот же Майкл Делл, Генри Форд и прочие — получается у единиц, и нет, не все там зависит от самого человека. Огромную роль играет фактор везения — т.е. торговать самосборными компутерами пробовали многие, но миллиардером стал один Делл
MSS>Так что лучше таки иметь образование.
Майкл Делл вообще-то лет эдак в 15 свою первую сделку провернул. И хвалить в данном случае стоит совсем не стремительную "быковскую" реакцию на "красный цвет". Тут налицо врожденный предпринимательский талант.
А что касается психологического фактора — то да, конечно, это важная составляющая успеха. Но без мастерства и везения — увы, психология бессильна.
СШ>Не надо грязи. Ничто не мешает человеку в ТЗ строго описать функционал, задать стандарты кодирования, описать скелет приложения, основные функции и передаваемые параметры, а затем протестировать и провести аудит кода на соответствие ТЗ. Rentacoder и Rentaguru это просто часть "пищевой цепочки" от момента придумывания идеи до момента смерти программы. Это часть конвеера. Тот, кто понимает как ими пользоваться, может экономить очень значительные деньги и получать при этом продукт высокого качества.
На мелких проектах такие напряги — это безумие. Там проще реализовать проект, чем написать "описание скелета приложения" и еще пять перечисленных документов.
А на крупных... RentaCoder все равно не годится.
Лоховский это сервис. Из серии МЛМщиков каких-нить. Серьезное отношение к нему — невозможно.
СШ>Так наладьте процесс, чтобы он не зависел от разработчика. Пусть всё будет задокументировано и разбито на модули, каждый из которых можно переписать заново. Если есть хороший процесс, то аутсорсинг разработки покроет все затраты на организацию чёткого процесса. Хотя здесь высоки требования к менеджменту и вам может не хватить знаний...
И что получается? Разработку проаутсорсили оболтусам с сайтика — они дешевле, зато получили потребность в качественных менеджерах, которые тоже недешевы?
Провал. У сервисов типа RentaCoder одно достоинство — цена. Это как раз "дешевка по определению" — т.е. любые факторы, повышающие цену, сразу снижают успех. Даже если с ценой повышается и качество.
>какая может быть проблема с исполнителями и принятием ими модели, если они работают по строгим ТЗ?
А если кастомер по ходу разработки захотел поменять "строгое ТЗ"? Что скажем кастомеру? "Извините, мы не можем?" А кастомер скажет — "до свиданья, мне нужно умение быстро решать проблемы и делать то, что работает".
Строгое ТЗ возможно только на длинных стратегических проектах (которые могут быть и у 3 человек, это реально). Но никто не пойдет с таким проектом на RentaCoder.
СШ>Кстати, на то процессы и существуют, чтобы нанимать менее квалифицированных программистов, чтобы они стали заменяемыми. Чем лучше процесс, тем ниже требуемая квалификация разработчика нижнего звена и выше квалификация менеджера проекта.
И деньги, сэкономленные на зарплате девелопера, уйдут на зарплату манагера.
СШ>В-третьих, появляется мобильность: сегодня нужен специалист определённого профиля, а завтра нет и что с ним делать?
А вот это — дело. Тут RentaGuru может и помочь.
СШ>В-шестых, при модели с аутсорсингом можно очень быстро как резко увеличить масштабы производства, так и резко уменьшить — по мере необходимости. При наличии сотрудников на постоянке этого не сделать.
И это — дело. Крупная офшорка может очень сильно "попасть", наняв много народу, а заказчик уменьшил объем работ — например, сдали какой-то этап проекта, его закрыли, а новой нагрузки — не нашлось.
СШ>То есть финансовые риски значительно снижаются. Появляется риск того, что работа не будет сделана в срок или не будет сделана вообще. С этим риском помогают сервисы. Во-первых, можно создать два одинаковых проекта и выбрать двух (трёх) исполнителей на один проект.
А как это поможет с соблюдением сроков?
>карательные меры самого сервиса должны заставлять исполнителя дорожить данными обязательствами.
Сложно сделать такой сервис, и чтобы там исполнители не имели по 0/1 законченных проектов
B>Майкл Делл вообще-то лет эдак в 15 свою первую сделку провернул.
Я видел полно подростков обоих полов, торговавших маечками и кроссами (девицы — соответственно косметикой) в 15 лет в собственной школе. А реально крутыми стали... те, у кого папа крутой
Деллами они не стали, короче.
B>А что касается психологического фактора — то да, конечно, это важная составляющая успеха. Но без мастерства и везения — увы, психология бессильна.
Здравствуйте, Maxim S. Shatskih, Вы писали:
B>>Майкл Делл вообще-то лет эдак в 15 свою первую сделку провернул.
MSS>Я видел полно подростков обоих полов, торговавших маечками и кроссами (девицы — соответственно косметикой) в 15 лет в собственной школе. А реально крутыми стали... те, у кого папа крутой
MSS>Деллами они не стали, короче.
Делл далеко не из бедной семьи. Отец, если память не изменяет, был занят в юрисприденции. Мама была биржевиком. Деньги в семье крутились всегда.
Здравствуйте, Maxim S. Shatskih, Вы писали:
>>какая может быть проблема с исполнителями и принятием ими модели, если они работают по строгим ТЗ?
MSS>А если кастомер по ходу разработки захотел поменять "строгое ТЗ"? Что скажем кастомеру? "Извините, мы не можем?" А кастомер скажет — "до свиданья, мне нужно умение быстро решать проблемы и делать то, что работает".
А на это и нужен сервис с гарантией оплаты типа нашего. В такой ситуации исполнителю гарантированно отдаются деньги за ту часть работы, которую он сделал. Дальше исполнитель принимает решение о работе над изменённым проектом сам.
MSS>Строгое ТЗ возможно только на длинных стратегических проектах (которые могут быть и у 3 человек, это реально). Но никто не пойдет с таким проектом на RentaCoder.
Строгое ТЗ возможно и для мелких проектов. Не детальное, до функций, но вполне строгое. Например, описаны все интерфейсы программы, скриншоты внешнего вида, use case, общая архитектура, форматы хранения данных, язык разработки, среда разработки и стандарты на код. Всё остальное — забота исполнителя.
СШ>>Кстати, на то процессы и существуют, чтобы нанимать менее квалифицированных программистов, чтобы они стали заменяемыми. Чем лучше процесс, тем ниже требуемая квалификация разработчика нижнего звена и выше квалификация менеджера проекта.
MSS>И деньги, сэкономленные на зарплате девелопера, уйдут на зарплату манагера.
И слава богу. Грамотный манагер это золото. И получать зарплату он должен золотом. Кроме того, сколько под нормальным манагером человек? 5? Всё равно очень приличная экономия получается.
СШ>>В-третьих, появляется мобильность: сегодня нужен специалист определённого профиля, а завтра нет и что с ним делать?
MSS>А вот это — дело. Тут RentaGuru может и помочь.
Мы на эту модель и ориентируемся.
СШ>>То есть финансовые риски значительно снижаются. Появляется риск того, что работа не будет сделана в срок или не будет сделана вообще. С этим риском помогают сервисы. Во-первых, можно создать два одинаковых проекта и выбрать двух (трёх) исполнителей на один проект.
MSS>А как это поможет с соблюдением сроков?
Один из трёх наверняка проект выполнит в срок. Риск срыва сроков снижается очень сильно. Но есть примерно 90% шанс заплатить тройную цену, если все три исполнителя сделают проект вовремя. Зато надёжность по срокам выше, чем у штатного сотрудника. Да и стоимость работы соизмерима.
>>карательные меры самого сервиса должны заставлять исполнителя дорожить данными обязательствами.
MSS>Сложно сделать такой сервис, и чтобы там исполнители не имели по 0/1 законченных проектов
Согласен. Но есть и иные способы обеспечения гарантий. Мы, например, даём возможность потребовать от исполнителя внести залог. То есть исполнитель в случае невыполнении обязательств теряет свои деньги. Мера непопулярная. Но зато она позволяет в достаточной мере гарантировать, что никому неизвестный исполнитель отвечает за свои слова как за качество, так и по срокам.
СШ>Строгое ТЗ возможно и для мелких проектов. Не детальное, до функций, но вполне строгое. Например, описаны все интерфейсы программы, скриншоты внешнего вида, use case, общая архитектура, форматы хранения данных, язык разработки, среда разработки и стандарты на код. Всё остальное — забота исполнителя.
Сумасшествие. Совокупность этих документов — более трудоемка, чем сам девелопмент ага, на мелких проектах оно так.
MSS>>А как это поможет с соблюдением сроков?
СШ>Один из трёх наверняка проект выполнит в срок. Риск срыва сроков снижается очень сильно. Но есть примерно 90% шанс заплатить тройную цену, если все три исполнителя сделают проект вовремя. Зато надёжность по срокам выше, чем у штатного сотрудника. Да и стоимость работы соизмерима.
Хых. Утроение цены ради гарантии соблюдения сроков, да и то не 100%ной? И кто на такое пойдет? И с какой бы балды "гуру" с сайта согласится работать _втрое_ дешевле штатного сотрудника?
Как показывает американская практика, временные сотрудники со стороны (контракторы) получают _больше_, чем свой персонал, и оказываются дороже для компании.
Экономия возможна только на географической и политической разнице — более дешевая страна или же город.
СШ>Согласен. Но есть и иные способы обеспечения гарантий. Мы, например, даём возможность потребовать от исполнителя внести залог.
Кидалово. Сразу, грубо и в лоб. Кто из исполнителей на такое пойдет? Схемы, когда надо сначала заплатить денежку, чтобы получить шанс получить работу — плавали, знаем.
Здравствуйте, yxiie, Вы писали:
Y>шареваре тут не совсем то. в шаровару идут скорее не юнцы, а обычные программисты утомленные аутсорсом/работой на дядю в поисках лучшей жизни, не понимая, что шаровара с программированием имеет не так уж и много общего.
А может кто-то не хочет всю жизнь программированием заниматься? Может, человек хочет попробовать себя в другом виде деятельности?
Ты бы еще драг-дилеров упомянул 
