По моим личным впечатлением большинство средних и больших проектов в Украине пробрасывают всю прибыль через Белиз под видом инвестиций, которые потом распиливают. Как не странно, всё это проекты с криминальным или околокриминальным финансированием :( В 2013 году это где-то 70%+ всех инвестиций которые были в стране, что тоже неоднозначно намекает. Уже не раз видел сервисы по быстрому созданию оффшора в Белизе — конторы регистрируют пачками на каких-то местных непонятных людей, но хоть полномочий у них нет — если будут долбать, есть на кого свалить. Случаев слива и присваивания конторы местными я пока не видел. Да и создают и меняют их с завидной частотой — тому тоже должна быть какая-то причина.
Вы не представляете как весело, когда московская студия ставит ценник в миллион рублей на iPhone приложение, в итоге нанимает фрилансера и платит ему 300 тысяч… они просто затягивают все сроки в 3 раза (4 месяца). Итальянцы управились за 90 тысяч и 3 недели, при этом их дизайн был просто замечательным и не в какое сравнение не входил с русским. Когда есть такие примеры, то как-то о качестве думать не приходится. Даже если и приходится, то основные проблемы которые я описал в статье у русских решать не принято — «лишь бы работало» и не более.
Ригидность — это неспособность менять свою точку зрения на вещи при получении новой информации, особенно когда она противоречит старым взглядам. Если рассмотреть хотя бы сотню различных когнитивных искажений, то на это уйдёт не один десяток статей, так что я описал только самое частое с чем приходится сталкиваться.
Срок выполнения заказа зависит от вовлечённости заказчиков / руководства в процесс выработки требований
Я лично на рынке СНГ и Европы выделяю 4 типа заказчиков
Люди некомпетентные, которым в первую очередь нужен результат — не участвуют в выработке требований, не могут взять на себя ответственность и сформулировать задачу которую нужно решить, грешат «радужными пони» потому что «хотелка и кошелёк» позволяет
Люди некомпетентные, у которых было достаточно много плохого опыта работы с фрилансерами и студиями — требуют хотя бы частичного подтверждения квалификации, но оценить её как-либо не в состоянии поэтому создают «ореолы» для компенсации. Участвуют в выработке требований достаточно активно, но могут грешить «вот я заказчик — я знаю как лучше».
Люди с средними и зачаточными навыками разработки, без навыков организации её процессов — из-за своей ригидности отвергают любые незнакомые подходы и инструменты. Тесты и аудит для них пустая трата времени, а в выработке требований не участвуют ввиду потребности в компенсации внутреннего напряжения: «как же так? я уже не такой умный ?».
Люди с хорошими навыками разработки, понимающие важность контроля качества, но никогда не осуществлявшие её. Они не ригидны и способны быстро учится любым премудростям. Чаще всего у них не возникает компенсаторных процессов, но с ними приходится долго возится в виду повышенных накладных расходов на коммуникацию из-за преодоления определённого порога вхождения.
Если второй тип некомпетентного заказчика с плохим опытом сотрудничества способен учится на своих ошибках и вникать в принципы организации процессов разработки — с ним можно сотрудничать достаточно долго и продуктивно. После реализации первого проекта такие люди просто «боготворят» и радуются, но и свернуть куда-то «на сторону» у них смелости не хватает, в итоге это вечные «прикрути то… прикрути сё...». С ними можно сотрудничать до тех пор пока они не захотят построить что-то очень большое в составе целой команды разработчиков, есть большая вероятность что её будет формировать фрилансер, но это довольно стихийные процессы требующие большего опыта, чаще всего они заканчиваются провалом, так как без опыта анализа организационных проблем пытаться чем-то руководить — «гиблое дело». Сотрудничество может затягиваться до 2-5 лет, а бюджеты проектов в среднем 3000-8000$ без поддержки и в зависимости от сложности. Сроки реализации порядка одного-трёх месяцев, но опять же зависит от качества выработки требований. Можно спокойно рассчитывать на долгосрочную поддержку со стабильным пассивным доходом.
В остальных случаях сотрудничать не получится — не выработаются требования к продукту и не будет ясно что нужно в итоге.
Вот в случае со сторонними разработчиками которые хотят развиваться и развивать продукты над которыми работают, ситуация немного сложнее: работают совместно, активно участвуют в выработке требований, но вот после завершения реализации чего-либо рассчитывать на долгосрочное сотрудничество не приходится — сами разбираются своими силами. Тут бюджеты и задачи обычно поменьше и попроще — в среднем 2000-3000$, а проекты обычно затягиваются на полтора месяца
Дальше CRUD'а дело не идёт, и наукоёмкие задачи встречаются крайне редко.
Последнее с чем мне приходилось работать — разработка средства распознавания reCaptcha на основе DeepLearning методов, получилась эффективность в 92% что более чем приемлемо. Недавно поставили задачу эмулировать поведение пользователей на сайте теми же методами, для того что бы обходить noCaptcha, правда пока не ясно как это осуществлять — в теории это должны быть генераторы на основе RBM с автоэнкодерами.
Подобного рода проекты — просто праздник…
В среднем ставка на рынке СНГ от 12 до 20$ в час не зависимо от компетентности.
В Штатах получается от 15$ и до 40$ в час, но возможно двойное налогообложение в некоторых случаях.
В следующей статье, или статьях, «RESTful services — you're doing it wrong» буду рассматривать особенности DDD при проектировании RESTful сервисов в рамках SOA с CQRS-ES'ом и реактивностями. Обычно пишут «одна таблица БД — один CRUD контроллер», статья о том как написать один контроллер для любого количества таблиц анализируя схему базы, по ней же автоматом генерировать правила серверной и браузерной валидации форм, выделять AAA сервисы.
Не понимаю о какой теории идёт речь?
Если нужен конкретный список литературы для ознакомления с базовыми понятиями, то лучше так и написать.
Понятие компенсаторных процессов является общепринятым в психологии, и я не думаю что его нужно подробно объяснять, по этому поводу можно почитать классические труды Альфреда Адлера. Я не хотел разбирать каждый частный случай когнитивного искажения и описывать как он влияет на организацию труда — их очень много и это задачи социальной психологии, а не психологии управления, можно почитать Майерса «Социальная психология», правда там довольно поверхностно. Считаю нецелесообраным использование профессиональной лексики психологов на этом ресурсе — старался излишне не усложнять и давать ссылки для ознакомления. Вот статья психолога для сравнения. Конкретный список литературы сформулировать не могу, так как писал всё с собственного опыта. Можно почитать популярной психологии: Берна «Игры в которые играют люди», и Козлова «Философские сказки для обдумывающих житье...», а вот Юнга читать без предварительной подготовки я не советую.
Это частный случай когнитивного искажения.
Я не видел случаев когда люди экономили на внедрении хорошего тестирования и аудита, и после этого тратили меньше в долгосрочной перспективе. Как пример могу привести RTB-биржу Datamind (Тинькова) на которую потратили три миллиона рублей и 3 года разработки, вместо года и одного миллиона — на аудите, организации и исследованиях «сэкономили». В итоге продали неизвестно кому потому что не смогли допилить самостоятельно…
С задачами выработки требований и контроля качества должен быть знаком непосредственно сам заказчик, иначе он получает «кота в мешке». Я под поддержкой подразумеваю долгосрочную поддержку — мониторинг нагрузки, различных угроз и администрирование в течении 10 лет, с сохранением работоспособности при обновлениях зависимостей, и возможность отката в случае проблем с обратной совместимостью. У вас же под поддержкой подразумевается доработки в процессе выработки требований — это непосредственная часть реализации проекта.
Можно по минимуму: внедрить менеджмент зависимостей, написать приёмочных тестов, и не нужно будет вечно переключаться в браузер да клацать F5 — уже значительная экономия времени, особенно со всякими LiveReload'ами фронтенда. После релиза можно провести нагрузочное тестирование каким-то jMeter'ом, да отпрофилировать под нагрузкой, чтобы понимать где есть узкие места. И этого уже вполне достаточно, но большинству фрилансеров не свойственно.
Согласен, но это статья задержалась на пару недель, и на очереди уже совсем другая… так что я решил оставить так как есть, кому будет интересно — почитают и скажут что об этом всём думают.
Понятное дело что тут можно разбить всё на 2 части и разбавить иллюстрациями для наглядности, но я решил просто побыстрее опубликовать и не заморачиваться. Если бы рассчитывал на большую часть «серой массы» — нарисовал бы комикс. Даже если прочтут половину — будет замечательно.
Если «минусуете» — пишите причину, чтобы можно было что-то обсуждать.
А то получается что «правда-матушка глазки режет», возникает внутреннее напряжение которое компенсируется «заминусовыванием».
Я понимаю что это всё можно спихнуть на мои пунктуационные ошибки, вольный стиль повествования и достаточно плохое знание русского.
Я потратил достаточно много времени на написание этой статьи — обратную связь можно дать просто из уважения, чтобы я понимал в чём заключаются мои ошибки и не допускал их в будущем.
Проблема в том что приспосабливаться под требования рынка, с личными когнитивными искажениями и коммуникационными барьерами, которые возникают из-за компенсаторных процессов, очень сложно — это достойно отдельной статьи.
Это решения для проектов в которых принято делегировать ответственность сторонним вендорам, при этом увеличивать вероятность отказа сервиса в целом. Большие базы данных, особенно аналитику лучше всегда держать при себе. Актуально для некомпетентных руководителей у которых нет возможности изначально проектировать масштабируемые сервисы, да и целевой аудитории у них не много — сотня человек для внутреннего использования, но не более. А если вспомнить недавнее падение Azure, так вообще становится гадко…
Плохое и слишком широкое позиционирование продуктов
Отсутствие отработанных методов построения сообществ пользователей и повышения их лояльности
Высокая неявная конкуренция — ригидные пользователи не готовы пробовать что-то новое из-за использования других продуктов которые могут решать те же задачи, хотя изначально предназначение у них может отличаться
Отсутствие гибких методов монетизации — в топку фримиумы, они устарели и уже есть пару интересных и более прибыльных методов монетизации, но о них я поведать не могу
Отсутствие отработанной архитектуры и порядка разработки реактивных приложений — очень много костылей повсюду, особенно что касается MVC c Push-оповещениями, которое на самом деле должно быть CQRS-ES'ом с RESTful SOA (его тоже мало кто умеет готовить)
Отсутствие контроля качества, порядка приёмочного тестирования, вертикального и горизонтального масштабирования, долгосрочной поддержки
В итоге подобные продукты занимают какую-то маленькую нишу, и не способны расти и привлекать новых клиентов без лишних вопросов типа «а для чего это очередное чудо ?», «а почему оно так глючить начало ?», «я так и не понял чем это лучше/хуже продукта Х ?».
По моему опыту работы со стартапами, могу сказать что их часто разрабатывают ригидные личности, развитие которых, как профессионалов, приостановилось на определённом уровне и инструментарии — они отказываются приспосабливаться под возрастающие требования рынка, либо изменчивые требования к стартапам из-за смены их позиционирования, и естественно не могут разрабатывать конкурентоспособные решения.
Личностный подход имеет кучу преимуществ так как можно осуществлять контроль существующих компенсаторных процессов психологических проблем, анализировать социальные связи, внутренние мотивации и коммуникационные барьеры в рамках существующего состава команды. Участвовать в предотвращении возможных конфликтов и построении жизнеспособных команд.
Мне даже приходилось видеть психоаналитиков которые решают эти проблемы в рамках какого-то очень важного персонала — всплывают достаточно интересные моменты, и естественно это в основном индивидуальный подход к каждому человеку отдельно.
Для любителей php / python / ruby конечно это сложно.
А для адептов node.js / java / golang это довольно обыденные задачи.
push'ы в браузер по sock.js / socket.io и в мобильные приложения встречаются в половине проектов.
Синхронизацию потоков — построение цепочек с зависимостями, возвращение и объединение, мало кто понимает.
А так у меня были наброски более-менее нормального Seed'а под Gulp.
Срок выполнения заказа зависит от вовлечённости заказчиков / руководства в процесс выработки требований
Я лично на рынке СНГ и Европы выделяю 4 типа заказчиков
Если второй тип некомпетентного заказчика с плохим опытом сотрудничества способен учится на своих ошибках и вникать в принципы организации процессов разработки — с ним можно сотрудничать достаточно долго и продуктивно. После реализации первого проекта такие люди просто «боготворят» и радуются, но и свернуть куда-то «на сторону» у них смелости не хватает, в итоге это вечные «прикрути то… прикрути сё...». С ними можно сотрудничать до тех пор пока они не захотят построить что-то очень большое в составе целой команды разработчиков, есть большая вероятность что её будет формировать фрилансер, но это довольно стихийные процессы требующие большего опыта, чаще всего они заканчиваются провалом, так как без опыта анализа организационных проблем пытаться чем-то руководить — «гиблое дело». Сотрудничество может затягиваться до 2-5 лет, а бюджеты проектов в среднем 3000-8000$ без поддержки и в зависимости от сложности. Сроки реализации порядка одного-трёх месяцев, но опять же зависит от качества выработки требований. Можно спокойно рассчитывать на долгосрочную поддержку со стабильным пассивным доходом.
В остальных случаях сотрудничать не получится — не выработаются требования к продукту и не будет ясно что нужно в итоге.
Вот в случае со сторонними разработчиками которые хотят развиваться и развивать продукты над которыми работают, ситуация немного сложнее: работают совместно, активно участвуют в выработке требований, но вот после завершения реализации чего-либо рассчитывать на долгосрочное сотрудничество не приходится — сами разбираются своими силами. Тут бюджеты и задачи обычно поменьше и попроще — в среднем 2000-3000$, а проекты обычно затягиваются на полтора месяца
Дальше CRUD'а дело не идёт, и наукоёмкие задачи встречаются крайне редко.
Последнее с чем мне приходилось работать — разработка средства распознавания reCaptcha на основе DeepLearning методов, получилась эффективность в 92% что более чем приемлемо. Недавно поставили задачу эмулировать поведение пользователей на сайте теми же методами, для того что бы обходить noCaptcha, правда пока не ясно как это осуществлять — в теории это должны быть генераторы на основе RBM с автоэнкодерами.
Подобного рода проекты — просто праздник…
В среднем ставка на рынке СНГ от 12 до 20$ в час не зависимо от компетентности.
В Штатах получается от 15$ и до 40$ в час, но возможно двойное налогообложение в некоторых случаях.
Если нужен конкретный список литературы для ознакомления с базовыми понятиями, то лучше так и написать.
Понятие компенсаторных процессов является общепринятым в психологии, и я не думаю что его нужно подробно объяснять, по этому поводу можно почитать классические труды Альфреда Адлера. Я не хотел разбирать каждый частный случай когнитивного искажения и описывать как он влияет на организацию труда — их очень много и это задачи социальной психологии, а не психологии управления, можно почитать Майерса «Социальная психология», правда там довольно поверхностно. Считаю нецелесообраным использование профессиональной лексики психологов на этом ресурсе — старался излишне не усложнять и давать ссылки для ознакомления. Вот статья психолога для сравнения. Конкретный список литературы сформулировать не могу, так как писал всё с собственного опыта. Можно почитать популярной психологии: Берна «Игры в которые играют люди», и Козлова «Философские сказки для обдумывающих житье...», а вот Юнга читать без предварительной подготовки я не советую.
Я не видел случаев когда люди экономили на внедрении хорошего тестирования и аудита, и после этого тратили меньше в долгосрочной перспективе. Как пример могу привести RTB-биржу Datamind (Тинькова) на которую потратили три миллиона рублей и 3 года разработки, вместо года и одного миллиона — на аудите, организации и исследованиях «сэкономили». В итоге продали неизвестно кому потому что не смогли допилить самостоятельно…
С задачами выработки требований и контроля качества должен быть знаком непосредственно сам заказчик, иначе он получает «кота в мешке». Я под поддержкой подразумеваю долгосрочную поддержку — мониторинг нагрузки, различных угроз и администрирование в течении 10 лет, с сохранением работоспособности при обновлениях зависимостей, и возможность отката в случае проблем с обратной совместимостью. У вас же под поддержкой подразумевается доработки в процессе выработки требований — это непосредственная часть реализации проекта.
Можно по минимуму: внедрить менеджмент зависимостей, написать приёмочных тестов, и не нужно будет вечно переключаться в браузер да клацать F5 — уже значительная экономия времени, особенно со всякими LiveReload'ами фронтенда. После релиза можно провести нагрузочное тестирование каким-то jMeter'ом, да отпрофилировать под нагрузкой, чтобы понимать где есть узкие места. И этого уже вполне достаточно, но большинству фрилансеров не свойственно.
А то получается что «правда-матушка глазки режет», возникает внутреннее напряжение которое компенсируется «заминусовыванием».
Я понимаю что это всё можно спихнуть на мои пунктуационные ошибки, вольный стиль повествования и достаточно плохое знание русского.
Я потратил достаточно много времени на написание этой статьи — обратную связь можно дать просто из уважения, чтобы я понимал в чём заключаются мои ошибки и не допускал их в будущем.
ригидныепользователи не готовы пробовать что-то новое из-за использования других продуктов которые могут решать те же задачи, хотя изначально предназначение у них может отличатьсяВ итоге подобные продукты занимают какую-то маленькую нишу, и не способны расти и привлекать новых клиентов без лишних вопросов типа «а для чего это очередное чудо ?», «а почему оно так глючить начало ?», «я так и не понял чем это лучше/хуже продукта Х ?».
Личностный подход имеет кучу преимуществ так как можно осуществлять контроль существующих компенсаторных процессов психологических проблем, анализировать социальные связи, внутренние мотивации и коммуникационные барьеры в рамках существующего состава команды. Участвовать в предотвращении возможных конфликтов и построении жизнеспособных команд.
Мне даже приходилось видеть психоаналитиков которые решают эти проблемы в рамках какого-то очень важного персонала — всплывают достаточно интересные моменты, и естественно это в основном индивидуальный подход к каждому человеку отдельно.
А для адептов node.js / java / golang это довольно обыденные задачи.
push'ы в браузер по sock.js / socket.io и в мобильные приложения встречаются в половине проектов.
А так у меня были наброски более-менее нормального Seed'а под Gulp.