Спасибо за статью! Не могли бы вы подробней объяснить момент договора купли-продажи долей ООО и возникновения не облагаемой суммы на счету компании? Решение об увеличении уставного капитала и продажа, судя по всему, -разные процессы? Т.е. продаются дополнительные доли?
Как не возникает доходов у продающих доли соучредителей?
Хорошо. Для условной выделенной команды за 8 лет, конечно необходимо генерировать прибыль. Сыграло то, что видение продуктов было вне команды, стартап на аутсорсе почти никогда не работает. Также, возможно, лучший результат был бы, если бы вы не бросали проекты, а делали пивоты (число проектов соответственно было бы меньше).
Скажите пожалуйста, как стандарт будет применяться на практике?
Раскладка по более узким позициям может быть полезной для тех, кто хочет стать продактом. Но на практике, для компаний, конечно, важны практические результаты, а не теоретические познания продуктового менеджера.
Насчет HR, увольнений, выбора технологий согласна. Но и люди заняты лишь частично, они не погружены в проект, миксуют их еще с 90% аутсорса. Это примерно нивелирует выгоду для предпринимателя (ему может быть удобней нанять людей для полного погружения). Это же относится и к затраченному времени. Вы с 90% условных человеко-часов получали стандартную прибыль студии, <10% человеко-часов ушло на эти проекты. С такими данными результат отличный. Но, конечно, если показатели не совсем грустные.
Все-таки команда, занимающаяся одним проектом, — очень важный фактор в оценке.
Очень интересная информация, спасибо что поделились. Немного непонятно, как работает схема покрытие разработки + доля, в чем смысл предпринимателю идти в студию на таких условиях?
По поводу результатов, они не такие плохие(доли в 5 развивающихся проектах), может быть у Вас были завышенные ожидания от технологичексого/другого инвестирования. Например, вот эти факты:
Результат в любом из случаев не радует. Даже если проекты не умирают, то денег все равно не приносят или приносят несоразмерно затраченному времени.
занятость на проектах своих и техинвестиционных была не более 10%.
как-то плохо коррелируют. Вы тратили 5-10% времени (при этом еще миксовали людей!?), получили 5 перспективных запущенных проектов на выходе. Очень неплохо.
Выделить отдельных людей, не занимающихся аутсорсом, конечно необходимо.
Отсутствие монетизации, как факт, ни о чем не говорит без других показателей (число пользователей, вовлечение и тд).
Вам нужно просто ознакомиться со страшной статистикой венчурного рынка, тогда по-другому посмотрите на результаты. Договора с предпринимателями — не технарями можно пересмотреть (но, опять же, сложная ситуация с большими долями на старте).
Соглашусь с мыслью о том, что в Angular приходится решать много проблем, которые создает сам Angular. Тем не менее, применять его в больших проектах можно. Возможно, ошибка в проекте автора в том, что Angular пытаются применять не как SPA-фреймворк.
Конкретные перечисленные пункты не совсем корректны. Документация не такая плохая, минификация кода- это просто отдельная задача, структурно не относящаяся к проблемам фреймворка, разработчиков на Angular наоборот стало слишком много. Предложение не наследовать скоупы может принести столько же проблем, сколько решит.
Интересно другое — сравнение ресурсов разработки в Angular и не Angular проектах на запуск/поддержку/расширение. Предлагаю product owner'ам поделиться своими впечатлениями, в новых статьях. Как раз сейчас Angular стал стандартом выбора для многих молодых проектов, и информация для оценки всех стадий развития может быть полезной.
Дело не в жанре, а в том, как будете нагружать рендеринг и сетку. Конечно, серьезных нагрузок Phaser не выдержит, но так как проект опенсорсный, вы можете попробовать свои сборки + свой клиент-сервер.
Менеджер — многоликий Шива. В программу включено: стратегия (! на первом месте, на практике до нее доползают 1%), геймдизайн, монетизация (без аналитики), диздоки, проектная документация, локализация, комьюнити менеджмент, финансы, юридические вопросы, и немного технических вопросов. При этом, как бы подразумевается, что это будет product и project в одном лице ?!
И все это только теория, представляю как ему поплохеет на практике…
Но для управления стандартными проектами, да. Тем более, у нас вообще не выпускают специалистов игровой отрасли (в США около 400 ВУЗов).
Вот что-то на дарте: vector math dart
А вот форк pixijs использующий SIMD: gameofbombs-pixi
Как не возникает доходов у продающих доли соучредителей?
Раскладка по более узким позициям может быть полезной для тех, кто хочет стать продактом. Но на практике, для компаний, конечно, важны практические результаты, а не теоретические познания продуктового менеджера.
Все-таки команда, занимающаяся одним проектом, — очень важный фактор в оценке.
По поводу результатов, они не такие плохие(доли в 5 развивающихся проектах), может быть у Вас были завышенные ожидания от технологичексого/другого инвестирования. Например, вот эти факты:
как-то плохо коррелируют. Вы тратили 5-10% времени (при этом еще миксовали людей!?), получили 5 перспективных запущенных проектов на выходе. Очень неплохо.
Выделить отдельных людей, не занимающихся аутсорсом, конечно необходимо.
Отсутствие монетизации, как факт, ни о чем не говорит без других показателей (число пользователей, вовлечение и тд).
Вам нужно просто ознакомиться со страшной статистикой венчурного рынка, тогда по-другому посмотрите на результаты. Договора с предпринимателями — не технарями можно пересмотреть (но, опять же, сложная ситуация с большими долями на старте).
Конкретные перечисленные пункты не совсем корректны. Документация не такая плохая, минификация кода- это просто отдельная задача, структурно не относящаяся к проблемам фреймворка, разработчиков на Angular наоборот стало слишком много. Предложение не наследовать скоупы может принести столько же проблем, сколько решит.
Интересно другое — сравнение ресурсов разработки в Angular и не Angular проектах на запуск/поддержку/расширение. Предлагаю product owner'ам поделиться своими впечатлениями, в новых статьях. Как раз сейчас Angular стал стандартом выбора для многих молодых проектов, и информация для оценки всех стадий развития может быть полезной.
И все это только теория, представляю как ему поплохеет на практике…
Но для управления стандартными проектами, да. Тем более, у нас вообще не выпускают специалистов игровой отрасли (в США около 400 ВУЗов).
Наверно, ближайшее будущее за кросс-компиляцией. Вопрос, насколько удобно отлаживать большие приложения через source-maps? Кто-нибудь практиковал?