Дмитрий Цапля
CEO along.pw - делаем приложения для образования, финансов и стартапов
Статья супер!
Круто! А через какой сервис писал код?
А с какой целью опенсорсить?
В целом триал это полезная вещь. Конкретно в суммаризаторе мы отказались его давать всем, потому что мы платим за API чатжпт и прочих сервисов, поэтому хотим сразу их окупать. Даем триал только тем, кто не купил без него
Статья огонь)
Аудитория: малый бизнес
Проблема: сложно разбираться в правовых вопросах, дорого нанимать юриста и оплачивать консультант+
Решение: gpt ассистент который умеет анализировать проблемы на человеческом языке и выдавать ответ с ссылками на правовые акты
Классная аналогия с инструкцией lego, продаёт)
Стоит еще отметить, что в идеале работа discovery-команды на этом не останавливается - команда дискавери работает параллельно с командой разработки
У нас половина часов от всего объема - это не написание кода, а продуктовая работа
По экономике: выстреливает не каждое приложение, поэтому их нужно делать много и отбивать затраты на провальные доходами от выстреливших
Либо углубляться в продукт и выводить unit-экономику в плюс (например сейчас у нас такая цель в проекте Summarizer)
С ревью - бывают трудности, с которыми мы научились справляться. С модераторами эппла сражаемся постоянно, но в целом ревью проходим, хоть иногда и с задержками
Привет, я СЕО along, можем в лс в телеге пообщаться, @dimtsaplia
Обычно разработчики и не зарабатывают с этого) Была даже статья о том, что математически нет смысла вписываться в стартап ради заработка от продажи своей небольшой доли в случае успеха. Там скорее люди ради нематериальных ценностей участвуют
То есть на позиции джуна/мидла вряд ли есть смысл это делать
Судя по моему опыту общения с фаундерами, ребята продают свою идею продукта senior разрабам из корпораций, где они сидят на высокой зп и им не хватает чего-то (интересных задач, изучения современного стека, самореализации). Или на крайний случай есть СТО в доле, который пилит первую версию.
Поэтому создать продукт "почти бесплатно" можно. Правда, это работает если СЕО имеет классный опыт, из-за которого разработчики присоединятся к проекту.
Не увидел в посте ничего про ваши хард скиллы. Ведь именно за них (то есть за экспертизу, компетенции и насмотренность) платят зп.
Приведу несколько примеров:
- У меня в компании есть сотрудница, которая занимается юр. вопросами, бухгалтерией, рисерчем и прочими штуками. Ее экспертиза исходит из ее высших образований и опыта в экономике и юриспруденции
- Все менеджеры проектов базово умеют кодить, понимают scrum-процесс, умеют делать оценки и проводить requirement engineering (то есть писать ТЗ, prd и еще кучу других артефактов)
Если вы хотите monkey job по ручному заполнению табличек/перетаскиванию карточек в jira, то за 70-80 тысяч вы не найдете ни одной вакансии. Такие процессы уже давно автоматизированы в крупных компаниях, а у стартапов нет денег на найм такого человека за столько денег.
Напишите, в чем ваши компетенции и знания, и вам можно будет сделать оффер
Ну надо же с чего-то начинать)
Отличная статья! Интересно еще, почему вы используете только селф-хостед решения (для гита например)?
Всем привет! Написал статью о том, как не слить все деньги, если работаешь с разрабами/студией
https://vc.ru/u/1218994-dmitriy-caplya/529882-kak-ne-slit-vse-dengi-esli-vy-zakazali-razrabotku
Еще у меня есть канал, там - про стартапы, студии разработки и продукт-менеджмент
Отличная статья, заметил что проблемами с сменой разработчиков страдают в основном в проектах за фикс, где подписывается ТЗ и берется аванс 50%.
Лучше работать по ТМ, расчитываться раз в месяц, сделать возможным завершение договора по инициативе любой из сторон (либо по какой-то причине, либо с предупреждением за месяц). Если разрабы тупят, то вы потеряете максимум месяц работы (а не полгода).
При этом надо сократить цикл обратной связи, настроить CI/CD и демо-стенд, который видит заказчик.
Аудитор это мастхэв, практикуем это с клиентами. Многие студии боятся пускать к себе такого аудитора, но это на самом деле решает кучу проблем с доверием. Главное чтобы аудитор не микроменеджил и не вмешивался в активный процесс
Я бы еще добавил, что аудитор должен смотреть на maintainability, архитектуру и кодстайл. Попросите студию врубить линтер кода в пайплайн и проверять кодстайл автоматически. Документацию можно и нужно генерить автоматически, это тоже защитит вас, когда разрабы начнут сливаться/тупить
Ну и надо выбирать популярный стек, чтобы потом найти себе под этот стек разрабов.
Также надо спрашивать про вовлеченность и прозрачность (писал про это тут https://vc.ru/u/1218994-dmitriy-caplya/580832-o-chem-stoit-dogovoritsya-s-studiey-razrabotki)
Супер, это важная фича для нас, мы тада не купили только из-за того что у них нет тредов
А на чём вы кстати пишете приложение? Мне было бы интересно с вами побольше пообщаться, если интересно то предлагаю в тг списаться (@dimtsaplia)
А вы для IT делаете или в целом для МСБ?
Для меня кажется важным еще треды (как в слаке) - чтобы можно было под сообщением общаться. Вы планируете это добавить?
Кстати, так и не понял сколько стоит ваш сервис) Для меня это очень важно, потому что по 8 баксов в месяц за сотрудника за слак было дорого платить, поэтому есть опенсорсный рокет чат (который просит деньги за пуш-уведомления кстати)
Мы пока так и не нашли решения, которое бы нас устраивало. Используем rocket chat как менссенджер, дискорд для звонков, гугл доки и ноушн для гайдов, ютрек как доску и клокифай для трекинга часов
Space от JetBarains - классное решение, но всё еще слишком сырое. Без мобильных приложений и десктопа особо нет пользы от корпоративного мессенджера
Кстати, посмотрел ваш продукт - как будто обрезанная версия tada team или что-то вроде того
Я бы на вашем месте сделал лучше побольше интеграций в существующие мессенджеры для создания задач из сообщений в любых мессенджерах и в любых досках. Хотя вроде уже где-то видел такое в виде бота для тг и слака.
«А мы так не договаривались» начинается, когда вы об этом действительно не договаривались, и каждый подумал, что будет так, как ему кажется
Поэтому я и советую всё проговорить перед началом. Это можно отразить в договоре, хотя не о всех вещах возможно договориться
Я не говорю, что требования не нужно писать. Я говорю о том, что нет смысла вписывать ТЗ в контракт и плясать потом вокруг него с бубном.
Энтерпрайз и продукт для бизнеса тут тоже ничем не отличается. Чем больше бюрократии и меньше гибкости, тем хуже и дороже получится результат
Так и не нужно бежать от доработок и делать подробное ТЗ. Ни один человек в мире не может сделать ТЗ, которое бы гарантировало отсутствие необходимости правок и доработок вне ТЗ
Нужно быть гибким и работать по ТМ . В agile есть понятие "конус неопределенности", я писал про это в предыдущем посте. Оценка всё равно никогда не будет точной, и заказчик никогда не попадёт в оценку (если конечно оценка не специально умножена на 4). С бэклогом нужно уметь работать, менять приоритеты и отказываться от фичей (или менять их)
При этом ты не можешь гарантировать договором то, что сотрудники студии будут приятными в общении, и что они будут давать хорошие предложения по продукту. Это можно определить только на практике
В договоре можно указать сторону, которая платит за простои и форму отчетности, но...
В договоре не получится прописать уровень вовлеченности и приятный опыт взаимодействия. Об этом нужно договариваться устно, а если ожидания не соответствуют реальности, то искать другую команду
Для того, чтобы это было возможно, не нужно сразу подписывать долгосрочные контракты. Также обязательно установите требования к кодстайлу, хорошей архитектуре и выбирайте студии с популярным стеком. Тогда проблем при смене команды будет меньше
Попросить контакты других заказчиков (а лучше попробовать их найти) и спросить, как работают люди
Также посмотрите портфолио и отзывы (если студия делает много заказов и есть публичные отзывы)
Узнайте, как внутри работает компания - сколько людей в штате, какой топ-менеджмент
Привлеките IT-эксперта со стороны, который проверит оценку в часах и скажет, не накручивают ли исполнители часы
Могу помочь с этим, @dimtsaplia в тг
Согласен, NTE это условие, которое перекладывает риски на исполнителя, при этом не дает доп. денег за эти риски.
У вас отличная статья, в итоге всё сводится либо к доверию, либо к выкупу команды на месяц фуллтайма и в итоге к тому же доверию. Наверное поэтому сейчас многие переходят на аутстафф, чтобы работать с in-house командой
Классная статья) Но всё таки, какие у кроссплатформы есть ограничения из твоего опыта?