[Анализ и проектирование систем, Развитие стартапа, Облачные сервисы] Дневник Производства 2.0 – стартап в стартапе
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Что сложнее: запустить стартап-проект в «чистом поле» или встроить его в готовый продукт? На самом деле одинаково сложно все.
Когда ты начинаешь что-то с нуля, то у тебя есть простор для творчества, одновременно с этим нет ничего – для запуска нужно много «человеко-ресурсов», а «бонус» – потенциально нет пользователей.
В случае с запуском внутреннего стартапа, нового направления развития внутри продукта, мы имеем: архитектурные ограничения, необходимость встроиться красиво, чтобы не повлиять на существующую несвязанную функциональность, фундамент и немного пользователей, которых мы услышали – они ждут.
Хочу рассказать о том, как проходит запуск нового направления МоегоСклада – Производство 2.0. С точки зрения бизнеса тема очень любопытна и интересна. Рассказываю в прямом эфире. Эта статья – мой взгляд на результаты первых двух недель работы, поэтому смогу погрузить в костер событий и не упущу ни одной шутки.
Краткое содержание:
- Мы
- Откуда берутся бизнес-требования
- Проектируем, предсказывая будущее
- Производство гробов и модель данных
- Как не сломить найти общий язык с бизнес-аналитиком, если ты архитектор
- Мы проработали, но нет. Автомобиль и рыба. Что общего?
Компания МойСклад – более 13 лет развивает и продает веб-сервис, упрощающий жизнь малому и среднему бизнесу. Сервис помогает вести складской учет, управлять продажами и закупками, печатать необходимые для ведения бизнеса документы и много-много всего. У нас налажен и постоянно развивается процесс разработки. Сделанные в первый день работы тикеты (на общепринятом языке — задачи) могут уже завтра быть на проде. Продукт большой и сложный, пользователи активно делятся пожеланиями. Мы придумываем, как сделать полезный для людей сервис — и делаем. И сейчас обновляем блок производства! Мы — команда «Производство».
Действующие лица первого этапа:
- Аскар – генеральный директор
- Олег – технический директор
- Максим – product owner, направляющий нас
- Тимур – бизнес-аналитик, который знает процессы производства
- Максим – тимлид команды разработки
- Я – системный аналитик
Вводная
Перескажу кратко вводную, которую в первый день спринта, 22 октября 2020-го, мы услышали от Аскара.
Производство в МоемСкладе есть уже давно и у него есть пользователи. Но оно сделано в минимальном исполнении. Можно создавать технологические карты и на их основе либо резервировать товары на складе под производство, либо одномоментно списывать товары и производить готовую продукцию. Это все.
Длительное время отдел продаж и техническая поддержка транслировали жалобы и пожелания по улучшению производства от пользователей. Несмотря на наличие такой обратной связи, количество пользователей растет. Производство часто запускают в действующих организациях, которые уже ведут учет с МоимСкладом и не хотят менять его. Это одна из основных причин, по которым число пользователей текущего производства растет: работа с двумя программами вызывает негодование.
В феврале 2020 года в МойСклад написал Тимур (теперь уже наш бизнес-аналитик), работавший тогда с учетом на реальном производстве, с описанием «как должно быть», прототипом и предложением о сотрудничестве. В итоге Аскаром принял решение подойти к развитию этого направления основательно и запустить Производство 2.0 – обновленное и умное.
Займемся производством
На протяжении длительного периода Тимур проводил анализ жалоб и пожеланий от пользователей, опрашивал сотрудников поддержки и отдела продаж. По результатам сформировал перечень функциональных возможностей, которые постепенно будут появляться в Производстве МоегоСклада. Они уже описаны как бизнес-требования и на этом можно было бы закончить – просто бери разработчиков и делай. Но не все так просто.
МойСклад внутри большой и сложный, да и бизнес-требования изменчивы. Так что наша команда поставила себе на старте такие задачи:
- Просмотреть весь запланированный бэклог, чтобы предсказать будущее осознать что нас ждет
- Спроектировать модель данных, чтобы определить базовые сущности, встроиться в текущую модель и избежать катастрофических миграций в будущем
- Определить законченные пользовательские сценарии, ключевые функции
- Сделать протоипы UI по итогам анализа и проектирования
- Создать задачи на разработку и делать
Просмотрев бэклог, мы, конечно, картину мира себе представили, но пока не начнешь делать конкретную задачу, все останется на уровне абстракции. Кстати, примерно на этом и умирают многие стартапы: планируют сделать одномоментно все, сразу и для всех, больше сидят в обсуждениях «что будет завтра», вместо того, чтобы вытащить одну каркасную задачку и начать проработку. Так что по итогам просмотра бэклога, с применением метода ранжирования, у нас появилась одна бизнес-задача на первый спринт, меняющая все текущее производство. Разрастется она очень масштабно.
Что помогло сделать первый шаг?
Макеты интерфейсов в виде Excel-таблички, которые «нарисовал» Тимур, наш бизнес-аналитик — представитель пользователей МоегоСклада, который пользовался им не так много, как мы. Его представление о продукте помогает понять, что люди хотят видеть на экране, а свежий взгляд приносит интересные идеи, заменяя наше «давайте переиспользуем». С применением этих макетов мы начали трогать процессы и проектировать логическую модель данных.
Рекомендация: перед проектированием системы изнутри, нарисуйте макеты пользовательского UI в любом виде, хоть карандашом на A4. Да, они 100 раз поменяются, и вообще нормальный UI/UX дизайнер потом все исправит, но они должны появиться, чтобы помочь.
На ней все держится. Модель данных
Пока мы проектировали модель данных, мы нашли все возможные проблемы, которые только могут возникнуть, определили все основные процессы, которые она должна покрывать. На модели мы проверили полный список известных бизнес-требований.
Если этот шаг не сделать на старте проекта, то есть шансы в какой-то момент «открыть Америку» или переделать все. Модель данных – это что-то элементарнее фундамента, это Земля, а на ней держится вообще все.
Обсуждая первое приближение созданной модели на мозгоштурме, я сразу обозначила: представим, что мы делаем все и сразу (и вчера). Так, мы брали очередную сущность и выясняли что с ней может происходить, кто на нее может влиять, как ее можно поменять, как она влияет на учет, как она связана с текущими сущностями в системе, где связи могут появиться внезапно. Важно уметь задавать правильные вопросы.
В целом обсуждение было построено примерно так:
- Для очередной сущности я спрашиваю: «Что это такое?» и «Что мы с этим можем сделать?».
- Тимур рассказывает нам о связанных процессах, показывает макеты, приводит примеры.
- Все задают много-много вопросов: «А можно так?», «А что, если...?», удивляются, и иногда кричат «Так нельзя!».
- Тимур убеждает, что можно и очень надо.
- От примера про сборку шкафа мы переходим к примеру про гробы («А если мы производим гробы из австралийского дуба, и нам заказывают модификацию из сосны...»).
- Смеемся, приходим к компромиссу, дорисовываем в модели данных связанные сущности, описываем ключевые параметры, оставляем заметки «уточнить позже».
- Фиксируем в статье «Вопросы и ответы» решения по бизнес-требованиям и ограничениям, если они появились в процессе обсуждения или наоборот, если были сняты.
Логическую модель сделали. В итоге у нас получился такой вот небольшой монстр с заметками и облаками.
Рекомендация номер два. Если стартап запускается с нуля, то простор для творчества есть и можно брать любых опытных разработчиков с рынка труда. При создании стартапа в готовом продукте, команда должна хотя бы базово знать его, уметь исследовать и не бояться этого. Не запускайте на ранних этапах внутренние проекты с новыми людьми – это может быть опасно для существующего продукта. Мы с Максимом ранее работали в других командах МоегоСклада. Для Максима роль тимлида – это рост внутри компании. Мое назначение в МоемСкладе: исследовать все и везде. Поэтому вопросов у нас к Тимуру было много. Чем больше вопросов, тем больше ответов. Чем больше ответов, тем больше шансов получить более надежное решение.
Убей в себе архитектора и научись слышать
Немного о проблемах, которые возникают при проектировании. Из-за профессиональной деформации в первую неделю у нас было много недопонимания в команде: Разработка vs Бизнес. Я, со знанием проблемы, старалась меньше кричать о том, что мы не вписываемся в текущую архитектуру, но все же кричала. И Максим кричал.
Что разработчики хотят от бизнеса на ранних этапах? Уверенности! Мы много раз разбивали уверенность Тимура о скалы и уводили его от задуманных бизнес-требований к попыткам сделать из того, что есть, или сделать проще. Так нельзя!
Концепция уже была проработана, а мы, такие умные, пришли и рушим все. Спасибо нашему продакту, который вовремя появлялся и тормозил давление на Тимура, аргументируя тем, что все решения по бизнесу были приняты уже давно. А позже и я окончательно отключила свое привычное системное мышление и встала на сторону «что нужно бизнесу», потянув за собой коллегу-разработчика.
Как только это внутреннее преобразование произошло, мы начали пытать Тимура правильно. И когда он сам хотел что-то упростить, мы просили рассматривать и вариант «усложнить». И да, все это происходило именно в процессе проектирования модели данных и тестирования на ней бизнес-требований.
Рекомендация номер три: разработчики от бизнеса ждут уверенности. Если вы — бизнес-аналитик и представляете бизнес, или же вы — бизнес-заказчик, будьте тверды в своих решениях до последнего, что бы разработчики не говорили. Проще – не значит правильно! Если сделать проще сегодня, то завтра доработки выльются в очень большие суммы. Лучше потратить чуть больше в начале и вылить на своего разработчика всю душу (пожелания), чем потом страдать. Разработчик должен знать о потенциальном будущем!
Не откладывай на завтра. НИКОГДА!
Как только мы сделали модель данных, более или менее утвердили процессы, выделили экраны и функции под первые тикеты на разработку, пришло время звать Олега, который лучше нас всех понимает и знает архитектуру МоегоСклада.
Нам нужно было обсудить миграцию для текущих пользователей — по ней было слишком много вопросов, а вести две версии производства вообще не хочется. И тут нашу командную уверенность опять опустили с небес на землю. Мы долго были в сомнениях по базовому бизнес-вопросу: а результатом производства по техкарте может быть более одного товара? Вроде, с бизнесом договорились уже, что результатом может быть только один товар.
Еще одна ошибка… Мы знали, что надо было проверить на проде процент пользователей-разборщиков, но тянули до последнего, хотя уже даже SQL-запросы подготовили. Если на проде есть прототип и можно проверить теорию на реальных данных, проверять надо сразу!
Если бы я не писала, а говорила, то это звучало бы как (читать с выражением): «М… Ну… Как бы сказать… Короче… Вот… Каждый третий…».
Техкарта, кстати, базовая сущность, вокруг которой крутятся все процессы. Нас опустило не просто с небес на землю, мы начали погружение на дно. Сердце почти остановилось.
Из-за чего эта ситуация произошла? Мы все знали, что в текущем производстве такое возможно, но вести учет по таким техкартам проблематично. Несмотря на наличие примера про разборку автомобиля от Максима, нашего продакта, Тимур убедил: это редкий кейс и вообще таких пользователей мало. Олег был сразу против отказа от такой возможности. Именно по его подсказке мы, наконец, добрались до прода, чтобы проверить гипотезу. Да и я на этом демо архитектуры вспомнила про разборку рыбы на голову, хвост и филе.
В завершении первого спринта мы пришли-таки к окончательному решению, и уже совсем скоро наша модель данных позволит детально проектировать и начинать разработку. Макеты детализируются, подключаем коллег по тестированию и UI/UX. Продолжаем творить!
Итого
Чтобы успешно и быстро начать стартап-проект:
- Изучите весь известный бэклог, чтобы знать будущее.
- Выберите фундаментальную задачу, которая делает/меняет все.
- Для внутреннего стартапа нужно подключать команду с опытом решения других задач в развитии продукта.
- Слушайте бизнес и дайте вашему бизнес-аналитику эликсир уверенности. Бизнес-требования важнее системных ограничений. Системные ограничения всегда можно преодолеть (это точно)!
- Прежде чем что-либо проектировать, посмотрите на систему глазами пользователей – нужны черновые макеты UI, которые обязательно будут изменены.
- Проектирование нужно начинать с модели данных
- Если есть возможность проверить теорию, проверяйте сразу, не откладывая до последнего.
О производстве в МоемСкладе:
www.moysklad.ru/vozmozhnosti/dlja-proizvodstva
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка мобильных приложений, Управление разработкой, Развитие стартапа] Разработка продукта: в какой парадигме работать?
- [Венчурные инвестиции, Развитие стартапа, Финансы в IT, IT-компании] Новости стартапов и венчура: IPO Airbnb, реальные сроки за крипту
- [Облачные сервисы, Разработка под Arduino, DIY или Сделай сам] Погода в доме или бюджетный мониторинг CO2, PM2.5, температуры и влажности на ESP32 и Blynk
- [Анализ и проектирование систем] Как Low Code системы увеличивают производительность ИТ-отдела
- [Управление медиа, Облачные сервисы, Звук] Вендор-лок для подкастов: к чему он приведет
- [Анализ и проектирование систем] Анализ WMS-систем для автоматизации бизнес-процессов
- [Программирование, Анализ и проектирование систем, Разработка систем связи, Гаджеты, Научно-популярное] JS8Call: Slack на коротких волнах
- [Учебный процесс в IT, Развитие стартапа, Карьера в IT-индустрии] YC Startup Library на русском: Работа на крупную технологическую компанию может стать ловушкой (Майкл Сибель) (перевод)
- [Python, Node.JS, Amazon Web Services, Google Cloud Platform, Видеоконференцсвязь] Психопомощь [online] | Product Weekend
- [Прототипирование, Читальный зал, Облачные сервисы, 3D-принтеры, Будущее здесь] Как 3D-печать меняет мир (перевод)
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_razvitie_startapa (Развитие стартапа), #_oblachnye_servisy (Облачные сервисы), #_proizvodstvo (производство), #_startapy (стартапы), #_mojsklad (мойсклад), #_analiz_biznesprotsessov (анализ бизнес-процессов), #_proektirovanie_sistem (проектирование систем), #_proektirovanie (проектирование), #_sistemnyj_analiz (системный анализ), #_biznesanaliz (бизнес-анализ), #_razrabotka_prilozhenij (разработка приложений), #_oblachnye_servisy (облачные сервисы), #_malyj_biznes (малый бизнес), #_srednij_biznes (средний бизнес), #_po_dlja_proizvodstva (ПО для производства), #_zapusk_startapov (запуск стартапов), #_blog_kompanii_mojsklad (
Блог компании МойСклад
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_razvitie_startapa (
Развитие стартапа
), #_oblachnye_servisy (
Облачные сервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 11:48
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Что сложнее: запустить стартап-проект в «чистом поле» или встроить его в готовый продукт? На самом деле одинаково сложно все. Когда ты начинаешь что-то с нуля, то у тебя есть простор для творчества, одновременно с этим нет ничего – для запуска нужно много «человеко-ресурсов», а «бонус» – потенциально нет пользователей. В случае с запуском внутреннего стартапа, нового направления развития внутри продукта, мы имеем: архитектурные ограничения, необходимость встроиться красиво, чтобы не повлиять на существующую несвязанную функциональность, фундамент и немного пользователей, которых мы услышали – они ждут. Хочу рассказать о том, как проходит запуск нового направления МоегоСклада – Производство 2.0. С точки зрения бизнеса тема очень любопытна и интересна. Рассказываю в прямом эфире. Эта статья – мой взгляд на результаты первых двух недель работы, поэтому смогу погрузить в костер событий и не упущу ни одной шутки.  Краткое содержание:
Компания МойСклад – более 13 лет развивает и продает веб-сервис, упрощающий жизнь малому и среднему бизнесу. Сервис помогает вести складской учет, управлять продажами и закупками, печатать необходимые для ведения бизнеса документы и много-много всего. У нас налажен и постоянно развивается процесс разработки. Сделанные в первый день работы тикеты (на общепринятом языке — задачи) могут уже завтра быть на проде. Продукт большой и сложный, пользователи активно делятся пожеланиями. Мы придумываем, как сделать полезный для людей сервис — и делаем. И сейчас обновляем блок производства! Мы — команда «Производство». Действующие лица первого этапа:
Вводная Перескажу кратко вводную, которую в первый день спринта, 22 октября 2020-го, мы услышали от Аскара. Производство в МоемСкладе есть уже давно и у него есть пользователи. Но оно сделано в минимальном исполнении. Можно создавать технологические карты и на их основе либо резервировать товары на складе под производство, либо одномоментно списывать товары и производить готовую продукцию. Это все.  Длительное время отдел продаж и техническая поддержка транслировали жалобы и пожелания по улучшению производства от пользователей. Несмотря на наличие такой обратной связи, количество пользователей растет. Производство часто запускают в действующих организациях, которые уже ведут учет с МоимСкладом и не хотят менять его. Это одна из основных причин, по которым число пользователей текущего производства растет: работа с двумя программами вызывает негодование. В феврале 2020 года в МойСклад написал Тимур (теперь уже наш бизнес-аналитик), работавший тогда с учетом на реальном производстве, с описанием «как должно быть», прототипом и предложением о сотрудничестве. В итоге Аскаром принял решение подойти к развитию этого направления основательно и запустить Производство 2.0 – обновленное и умное. Займемся производством  На протяжении длительного периода Тимур проводил анализ жалоб и пожеланий от пользователей, опрашивал сотрудников поддержки и отдела продаж. По результатам сформировал перечень функциональных возможностей, которые постепенно будут появляться в Производстве МоегоСклада. Они уже описаны как бизнес-требования и на этом можно было бы закончить – просто бери разработчиков и делай. Но не все так просто. МойСклад внутри большой и сложный, да и бизнес-требования изменчивы. Так что наша команда поставила себе на старте такие задачи:
Просмотрев бэклог, мы, конечно, картину мира себе представили, но пока не начнешь делать конкретную задачу, все останется на уровне абстракции. Кстати, примерно на этом и умирают многие стартапы: планируют сделать одномоментно все, сразу и для всех, больше сидят в обсуждениях «что будет завтра», вместо того, чтобы вытащить одну каркасную задачку и начать проработку. Так что по итогам просмотра бэклога, с применением метода ранжирования, у нас появилась одна бизнес-задача на первый спринт, меняющая все текущее производство. Разрастется она очень масштабно. Что помогло сделать первый шаг? Макеты интерфейсов в виде Excel-таблички, которые «нарисовал» Тимур, наш бизнес-аналитик — представитель пользователей МоегоСклада, который пользовался им не так много, как мы. Его представление о продукте помогает понять, что люди хотят видеть на экране, а свежий взгляд приносит интересные идеи, заменяя наше «давайте переиспользуем». С применением этих макетов мы начали трогать процессы и проектировать логическую модель данных. Рекомендация: перед проектированием системы изнутри, нарисуйте макеты пользовательского UI в любом виде, хоть карандашом на A4. Да, они 100 раз поменяются, и вообще нормальный UI/UX дизайнер потом все исправит, но они должны появиться, чтобы помочь. На ней все держится. Модель данных Пока мы проектировали модель данных, мы нашли все возможные проблемы, которые только могут возникнуть, определили все основные процессы, которые она должна покрывать. На модели мы проверили полный список известных бизнес-требований. Если этот шаг не сделать на старте проекта, то есть шансы в какой-то момент «открыть Америку» или переделать все. Модель данных – это что-то элементарнее фундамента, это Земля, а на ней держится вообще все. Обсуждая первое приближение созданной модели на мозгоштурме, я сразу обозначила: представим, что мы делаем все и сразу (и вчера). Так, мы брали очередную сущность и выясняли что с ней может происходить, кто на нее может влиять, как ее можно поменять, как она влияет на учет, как она связана с текущими сущностями в системе, где связи могут появиться внезапно. Важно уметь задавать правильные вопросы. В целом обсуждение было построено примерно так:
Логическую модель сделали. В итоге у нас получился такой вот небольшой монстр с заметками и облаками.  Рекомендация номер два. Если стартап запускается с нуля, то простор для творчества есть и можно брать любых опытных разработчиков с рынка труда. При создании стартапа в готовом продукте, команда должна хотя бы базово знать его, уметь исследовать и не бояться этого. Не запускайте на ранних этапах внутренние проекты с новыми людьми – это может быть опасно для существующего продукта. Мы с Максимом ранее работали в других командах МоегоСклада. Для Максима роль тимлида – это рост внутри компании. Мое назначение в МоемСкладе: исследовать все и везде. Поэтому вопросов у нас к Тимуру было много. Чем больше вопросов, тем больше ответов. Чем больше ответов, тем больше шансов получить более надежное решение. Убей в себе архитектора и научись слышать Немного о проблемах, которые возникают при проектировании. Из-за профессиональной деформации в первую неделю у нас было много недопонимания в команде: Разработка vs Бизнес. Я, со знанием проблемы, старалась меньше кричать о том, что мы не вписываемся в текущую архитектуру, но все же кричала. И Максим кричал. Что разработчики хотят от бизнеса на ранних этапах? Уверенности! Мы много раз разбивали уверенность Тимура о скалы и уводили его от задуманных бизнес-требований к попыткам сделать из того, что есть, или сделать проще. Так нельзя! Концепция уже была проработана, а мы, такие умные, пришли и рушим все. Спасибо нашему продакту, который вовремя появлялся и тормозил давление на Тимура, аргументируя тем, что все решения по бизнесу были приняты уже давно. А позже и я окончательно отключила свое привычное системное мышление и встала на сторону «что нужно бизнесу», потянув за собой коллегу-разработчика. Как только это внутреннее преобразование произошло, мы начали пытать Тимура правильно. И когда он сам хотел что-то упростить, мы просили рассматривать и вариант «усложнить». И да, все это происходило именно в процессе проектирования модели данных и тестирования на ней бизнес-требований.  Рекомендация номер три: разработчики от бизнеса ждут уверенности. Если вы — бизнес-аналитик и представляете бизнес, или же вы — бизнес-заказчик, будьте тверды в своих решениях до последнего, что бы разработчики не говорили. Проще – не значит правильно! Если сделать проще сегодня, то завтра доработки выльются в очень большие суммы. Лучше потратить чуть больше в начале и вылить на своего разработчика всю душу (пожелания), чем потом страдать. Разработчик должен знать о потенциальном будущем! Не откладывай на завтра. НИКОГДА! Как только мы сделали модель данных, более или менее утвердили процессы, выделили экраны и функции под первые тикеты на разработку, пришло время звать Олега, который лучше нас всех понимает и знает архитектуру МоегоСклада. Нам нужно было обсудить миграцию для текущих пользователей — по ней было слишком много вопросов, а вести две версии производства вообще не хочется. И тут нашу командную уверенность опять опустили с небес на землю. Мы долго были в сомнениях по базовому бизнес-вопросу: а результатом производства по техкарте может быть более одного товара? Вроде, с бизнесом договорились уже, что результатом может быть только один товар. Еще одна ошибка… Мы знали, что надо было проверить на проде процент пользователей-разборщиков, но тянули до последнего, хотя уже даже SQL-запросы подготовили. Если на проде есть прототип и можно проверить теорию на реальных данных, проверять надо сразу! Если бы я не писала, а говорила, то это звучало бы как (читать с выражением): «М… Ну… Как бы сказать… Короче… Вот… Каждый третий…». Техкарта, кстати, базовая сущность, вокруг которой крутятся все процессы. Нас опустило не просто с небес на землю, мы начали погружение на дно. Сердце почти остановилось.  Из-за чего эта ситуация произошла? Мы все знали, что в текущем производстве такое возможно, но вести учет по таким техкартам проблематично. Несмотря на наличие примера про разборку автомобиля от Максима, нашего продакта, Тимур убедил: это редкий кейс и вообще таких пользователей мало. Олег был сразу против отказа от такой возможности. Именно по его подсказке мы, наконец, добрались до прода, чтобы проверить гипотезу. Да и я на этом демо архитектуры вспомнила про разборку рыбы на голову, хвост и филе. В завершении первого спринта мы пришли-таки к окончательному решению, и уже совсем скоро наша модель данных позволит детально проектировать и начинать разработку. Макеты детализируются, подключаем коллег по тестированию и UI/UX. Продолжаем творить! Итого Чтобы успешно и быстро начать стартап-проект:
О производстве в МоемСкладе: www.moysklad.ru/vozmozhnosti/dlja-proizvodstva =========== Источник: habr.com =========== Похожие новости:
Блог компании МойСклад ), #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ), #_razvitie_startapa ( Развитие стартапа ), #_oblachnye_servisy ( Облачные сервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 11:48
Часовой пояс: UTC + 5