В честь нашего 6-летия и как своего рода дополнение к моей статье 15 уроков из 15000 часов финтех-предпринимательства, Я хочу опубликовать некоторые из моих самых больших ошибок, чтобы другие предприниматели могли их избежать. 

Примечание редактора: 3 * 2 = 6 и 3 ** 2 = 9, так что название все еще связано с нашим 6-м днем рождения. Вот почему так важно научиться программировать!

 

Прежде всего, перед списком, если вы хотите стать техническим специалистом, вы должны научиться программировать. Может быть, это очевидно, а может, и нет.  Изучение кода позволило мне чтобы создать первую версию и ежедневно позволять мне понимать, почему разработчики делают то, что они делают. В течение определенного периода времени мне очень нравилось кодировать и пачкать руки с API и т. Д. Курс машинного обучения позволил мне еще более уверенно взаимодействовать не только с нашими специалистами по данным, но и с техническими директорами клиентов и партнеров.

Я делал ошибки, и более опытные люди объясняли мне, почему они были ошибками. Многие основатели могут развить в себе комплексы превосходства, но знание собственных ошибок помогает вам оставаться в отношениях со своими сотрудниками и сохранять ясную голову.

А теперь перейдем к списку.

 

1. MVP - сука

Вам нужны деньги, чтобы построить бизнес, но каждый инвестор хочет видеть минимально жизнеспособный продукт (MVP). Без него ваша идея - или мечта, с точки зрения инвестора. Они скажут, что мечты прекрасны, но в них не стоит вкладывать деньги. 

Итак, вы пытаетесь создать MVP как можно быстрее. В конце концов, это минимум.

Вы собираете вещи вместе; вы учитесь на ходу, и каждый день кажется, что вы многого достигли. Затем вы понимаете, что написали одну строку кода и создали две новые ошибки. Вы выбираете ярлыки, и, поскольку вам нужно, чтобы они работали только для нескольких пользователей на этапе MVP, вы пропускаете масштабируемость. Это компьютеры, они могут делать что-то быстро. Насколько плохо может стать от 50 до 5000 пользователей?

Что касается меня, я не знал всех лучших практик, таких как тестирование, документирование и подготовка к масштабируемости. Целью было создание базового продукта для сбора средств, а не создание корпоративной версии. Я написал бэкэнд, используя фреймворк Ruby on Rails, но фронтенд на прямом JavaScript и jQuery. Поначалу это кажется разумным, и в то время интерфейсные фреймворки не были так популярны. Но отказ от использования фреймворка во внешнем интерфейсе, вероятно, стоил нам одного года рефакторинга и переосмысления, потому что масштабируемость и гибкость отсутствовали, и это привело к длительной загрузке пользователя. Неэффективность также означала высокие затраты на облачный хостинг и обработку. Не говоря уже о том, чтобы объяснять (и заново открывать) свой собственный код разработчикам, потому что моя документация была минимальной, а концепции финтеха могут быть довольно сложными для программистов, не разбирающихся в финансах.

Вам, вероятно, потребуется 3-6 месяцев, чтобы создать MVP с нуля, и еще несколько месяцев, чтобы набрать обороты. В то же время вам необходимо привлекать средства, но инвесторы просто хотят видеть рост и доход. Чтобы обеспечить всемогущий доход и поддержку, многие новые основатели будут пытаться перейти от MVP прямо к корпоративному качеству. Но тогда продажи упадут, потому что это будет не корпоративного качества, а лишь минимально жизнеспособным. 

Когда вы создаете свой MVP, по крайней мере, планируйте масштабируемость и эффективность. Никто не может с самого начала подготовиться к будущему, потому что вы не знаете, сработает ли это вообще. Но всегда помните о будущих технических проблемах и с самого начала старайтесь их максимально смягчить.  

После сбора средств и найма разработчиков вы можете захотеть провести рефакторинг кода и переоценить архитектуру, прежде чем сосредоточиться на дополнительных функциях, пользователях и доходах. Это предварительное вложение времени может предотвратить несколько серьезных проблем в будущем. Вы построили минимально в конце концов, жизнеспособный продукт, а не конечный оптимальный продукт.

Один из способов избежать стадии MVP и создания необходимого продукта с самого начала - это собрать миллионы целиком на идею, что очень распространено в Кремниевой долине. Конечно, это привилегия лишь для некоторых - серийных предпринимателей с большим опытом, друзей с венчурным капиталом или крупного бизнес-ангела или старшего отраслевого профессионала с большим количеством контактов. Для остальных из нас несколько вид MVP будет необходим, прежде чем увидеть какие-либо доллары инвестора или проценты вообще.

 

2. Вход в систему с каждым Томом, Диком и Гарри - я имею в виду Facebook, Twitter, Linkedin, Google, а теперь и Apple

Вы можете быть в инклюзивном духе. Возможно, пользователь написал вам письмо с вопросом, когда он сможет войти в систему через Facebook. Итак, вы смотрите документацию, и, замечательно, это всего лишь несколько строк кода. Но вы открыли ящик Пандоры. Как только «несколько строк кода» разрастутся до многих и вы, наконец, добьетесь того, чтобы процесс аутентификации работал с вашими системами, вам необходимо интегрировать его во все каналы доставки. Если у вас есть одно приложение на iOS, может быть, это не так уж и плохо. Но когда у вас есть веб-сайт, приложения для Android и iOS и голосовые системы, такие как Alexa и Google Home, вам необходимо добавить функцию входа для всех из них.

Затем вас могут заставить добавить других, например, войти в Apple для пользователей iPhone (см. Пункт 4.8 их Положений и условий), если вы хотите продолжать предоставлять свои услуги через их платформу. 

Теперь, когда у вас есть 6 разных частей кода, по одному для каждого канала доставки, все готово. Пока один из API не изменится, и вам не нужно будет исправлять код по всем каналам. Google и Apple не беспокоятся о том, что их изменения нарушат ваше крошечное приложение, но если это произойдет, вы окажетесь в беде.

Иногда даже пользователи не могут понять, как они регистрировались - через Facebook или Twitter? Если пользователя это сбивает с толку, представьте, каково это создать все эти методы входа, а затем управлять ими всеми - и замешательство клиента, когда его учетная запись не отражает последнее изменение, которое они внесли, потому что они вошли в систему с помощью другой метод. 

Интеграции входа всегда приглашают больше интеграций входа

Если вам не нужны данные, выходящие за рамки аутентификации (например, изображения из Facebook или информация о пользователе из Google), будьте исключительны: используйте только имя пользователя или адрес электронной почты и исключите различные другие методы входа в систему. Когда у вас положительный денежный поток и вы можете позволить разработчику только аутентификацию, вы можете подумать о добавлении нескольких методов аутентификации. 

 

3. Искушение без необходимости перекодировать элементы 

Подобно тому, как несколько методов аутентификации - это «всего лишь несколько строк кода», вы услышите, как разработчики говорят: «Код слишком сложен. Позвольте мне восстановить его, и он будет намного эффективнее ». Нажмите кнопку паники!

У разработчиков есть стремление сделать свой код эффективным и чистым, а по мере добавления новых функций код становится сложным. Но кодирование - это только одна часть, и в сложных системах, таких как человеческое тело и климат, небольшие изменения в одном месте кода могут иметь серьезные последствия позже или где-то еще.

Более того, правильное управление продуктом - это не просто кодирование. Когда код будет готов, группа обеспечения качества (QA) должна его протестировать. Этот процесс неизменно приводит к длительному возврату и обратно (см. Sin 6 ниже). Затем его необходимо стабилизировать. Если что-то важное изменится, сообщения и дизайн, возможно, придется подправить. Возникают непредвиденные последствия, и внезапно появляются жалобы клиентов. 

Не чините то, что не сломано. Мы сделали это и заплатили высокую цену за время запуска, стабильность и качество. 

 

4. Непонимание того, как управлять разработчиками и мотивировать их.

В сфере технологий разработчики буквально создают (и ломают) ваш продукт. Люди, которых привлекает разработка программного обеспечения, представляют собой особую породу, и вы должны понимать, как они работают. Вы можете проработать в отрасли 20 лет и руководить сотнями нетехнических специалистов, но все эти знания и опыт могут не помочь в работе с разработчиками. 

Непонимание их мотивов и того, как они действуют, - большая ошибка. Это приводит к недопониманию, задержкам и головным болям. В процессе найма вы встретите множество разработчиков, которым нужна высокая оплата, высокая автономия и гибкий график. Большинству не нужны ежедневные обзоры, жесткие сроки и сверхурочная работа. Отнеситесь к этим соображениям серьезно.

Сейчас, как никогда, удаленная работа стала реальной возможностью для разработчиков, и весь мир нанимает их. Лучшие будут работать там, где с ними лучше всего обращаются. И вы не хотите, чтобы недовольные сотрудники выпускали некачественный продукт, особенно когда вам нужно исправить в последний момент перед тем, как представить его инвесторам. Счастливые разработчики сделают для вас исключение сверхурочной работы; несчастные могут просто исчезнуть. 

Ты можешь читать вся моя статья о работе с разработчиками.

 

5. Отказ от автоматизации тестирования с самого начала

Как и безопасность, тестирование кода часто считается необязательным и пустой тратой времени. Но по мере роста команды и продукта сложность вынуждает проводить тестирование. Вы не можете интегрировать компонент в сложную систему без какого-либо тестирования, иначе вы будете готовы столкнуться с последствиями для клиента, когда производство остановится и начнет выдавать коды ошибок пользователям.

Мы всегда проводили модульное тестирование, то есть тестировали каждый отдельный компонент по отдельности, прежде чем присоединять его к системе. Однако мы начали целостное автоматическое интеграционное тестирование только с 2019 года. Основной причиной было отсутствие ресурсов для повторного тестирования всей системы при каждом обновлении. Пока работала обновленная часть, мы предполагали, что будет работать вся система. 

Автоматизация тестирования, особенно для интеграции, значительно упрощает тестирование и повторное тестирование каждой части сайта для каждой интеграции. Поскольку обычно неизвестно, что изменится во всей системе из-за нового модуля, интеграционное тестирование должно охватывать весь сайт. Неавтоматизированный, это очень утомительно, и QA тратят много времени на рутинные задачи. Но после автоматизации они освобождаются.

Это ведет к непрерывной интеграции, при которой новый код добавляется постоянно, а не в больших обновлениях. Если ваше тестирование не автоматизировано, вы ждете, пока будет готово много мелких изменений, затем выпускаете их все вместе, поэтому вы тестируете всю систему один раз. Но как только рутинное тестирование всего продукта будет автоматизировано, можно будет внедрить непрерывную интеграцию, не тратя ресурсы QA на повторное тестирование.

 

6. Недооценка времени выпуска: кодирование (1x), QA (2-3x), стабилизация (2-3x)

Когда вы имеете дело с технологиями, особенно если вы приехали не из технического мира, кодирование кажется на первый план. Вы хотите создать технический продукт, вы его кодируете и готово, верно? Конечно, если вам это не нужно для работы.

Вы потратите 1 неделю на разработку. Затем QA тестирует все (что не может быть автоматизировано), тикеты пишутся, и код возвращается разработчикам для исправления ошибок. Затем QA получают измененный код, и процесс начинается заново, как правило, на время разработки, в 2-3 раза превышающее первоначальный. Когда вы будете готовы запустить новый код в производство, в случае больших данных и сложных функций вам придется потратить в 2-3 раза больше времени на разработку, чтобы обеспечить стабильность и качественную производительность. 

В сумме вы перешли с 1 недели выпуска (первоначальная оценка для новых технических специалистов) до 5-7 недель. Если вы не готовы к такому раздуванию сроков, вы будете слишком много обещать клиентам и будете слишком сильно давить на свою команду, если срок будет пропущен. 

Предполагается, что у вас изначально есть надлежащая документация по коду, а разработчики уже понимают, что нужно UX, UI и управлению продуктами.

Создание качественного технологического продукта требует больше времени, чем думает большинство людей.

 

7. Не обращать внимания на разницу в производительности между хорошими и плохими программистами

На ранних этапах существует сильное давление, чтобы вывести как можно меньше денег. Это приводит к найму младших разработчиков для проектов, которые не следует доверять младшим разработчикам. Позже здорово нанять младших разработчиков, чтобы они помогали с небольшими задачами, но ядро вашего бизнеса - это ваши технологии - необходим хороший опытный разработчик. В противном случае вы потратите много времени на переработку старого кода для обеспечения масштабируемости, стабильности и эффективности. Плата за хорошего разработчика с достаточным опытом в будущем окупится.

Для этого требуются оба качества: опыт и способность. Некоторые младшие разработчики - отличные программисты, они просто не замечают будущих проблем, которых нет у опытных программистов. И наоборот, 10-летний опыт не обязательно означает хорошие навыки программирования. Вам нужно убедиться, что присутствуют оба качества. Узнав из этого, мы теперь проводим гораздо больше времени в процессе найма, чтобы убедиться, что мы получили правильного кандидата. Затем, в течение испытательного срока, мы тщательно оцениваем их работу, и любые тревожные сигналы немедленно устраняются.

При объеме дополнительной работы, необходимой для отладки, перекодирования, контроля качества и перепроектирования из-за плохого кода, разница в производительности между хорошим и плохим или неопытным разработчиком может составлять 1000 раз.

 

8. Искушение создать все «впечатления» внутри компании

Каждая компания хочет предоставить своим пользователям качественный опыт. Когда вы отправляетесь в путь к созданию этого опыта, возможно, у вас уже есть серверная часть. Может быть, у вас даже есть несколько клиентов, которые используют ваш API. Предоставить эти данные клиентскому интерфейсу должно быть очень легко, не так ли?

Разумеется, обслуживание данных - это просто. Собственно создаете интерфейс? Это совсем другая история. Фронтенд громоздкий. Во-первых, графика - вам понадобится дизайнер, чтобы сделать эту графику. API - это просто конечные точки, весь текст и код. Да, и графику нужно будет масштабировать для правильного отображения на разных разрешениях экрана и в разных браузерах. А кому не нужно мобильное приложение? Это связано со своими собственными проблемами, такими как типы принудительного входа в систему (см. 2 выше), несколько операционных систем и различное оборудование.

Моя рекомендация: вам придется создать много внешнего интерфейса, но если вы можете купить готовые компоненты у третьих лиц, которые позволят вам охватить большинство сценариев (ОС, оборудование, размер экрана и т. Д.), Покупайте готовые компоненты. Ваш продукт отличается внутренним кодом и дизайном внешнего интерфейса, а не основным кодом внешнего интерфейса. Если вы можете его купить, избавьтесь от головной боли тестирования 15 различных браузеров, планшетов и телефонов. Вам не нужно строить все самостоятельно; может быть решение о покупке по разумной цене. Или даже с открытым исходным кодом, если повезет. Но не поддавайтесь убеждению, что открытый исходный код всегда стоит экономии, потому что иногда премиум-версия решит ваши потребности без каких-либо дополнительных затрат времени на разработку. 

 

9. Непонимание различий в ролях в техническом контексте

Еще одно заблуждение тех, кто не имеет технического образования, заключается в том, что все технические должности более или менее одинаковы. Конечно, разработчики - это backend / frontend, пользовательский интерфейс отличается от инфраструктуры. В самом начале это может быть даже правдой. Когда есть только вы (и, возможно, еще пара), все роли смешиваются. Но по мере роста компании дифференциация и специализация становятся необходимыми, и их запутывание может стать дорогостоящей ошибкой во времени и качестве. 

Первый пример: дизайн. Есть дизайнеры для пользовательского интерфейса (UI) и есть дизайнеры для пользовательского интерфейса (UX). Пользовательский интерфейс требует творчества, поэтому все выглядит гладко и приятно. UX - это больше о структуре: как пользователи проходят через систему? Что произойдет, если здесь произойдет ошибка, перейдет ли пользователь на экран A или экран B? Имеет ли этот дизайн смысл в контексте того, откуда только что пришел пользователь, или он просто создает путаницу?

Незнание разницы между UX и UI может привести к созданию визуально привлекательных продуктов, которые расстраивают и сбивают с толку пользователей. Вы не просто продаете внешний вид, вы продаете опыт. Убедитесь, что это стоит денег для клиентов, иначе они уйдут в другое место.

Я также ошибочно принял разработчиков программного обеспечения и персонал DevOps, что привело к усилению рабочей нагрузки на наших разработчиков. Технологические системы, особенно такие сложные, как наша, не являются исключительно кодом (как упоминалось в Sin 6). Большие данные также раздвигают границы возможностей систем, поэтому стабильность и доступность становятся главным приоритетом. Конечно, в современном мире время безотказной работы 100% считается само собой разумеющимся, и несоблюдение этого требования заметно сразу. У нас уже есть 1.5 DevOps, и, возможно, потребуется нанять еще одного, чтобы иметь возможность добавлять больше AI-сервисов.

Ваши разработчики, как серверные, так и внешние, сосредоточены на коде и алгоритме. DevOps необходим, чтобы обеспечить наличие вычислительной мощности для выполнения этого кода, и он должен быть достаточно стабильным, чтобы клиенты были довольны. Не путайте DevOps и разработку программного обеспечения.

 

9а. Грехи другого

Мы получили несколько проницательных предостережений от Джелле ван Моурик, читателя на Facebook. Мы просто разместим их здесь, в этом заголовке (мы немного перефразировали и, конечно же, добавили свой вкус):

  • Не заставляйте программистов кодировать то, что они не кодируют. Другими словами, не пытайтесь заставить внутреннего программиста работать над кодом внешнего интерфейса и наоборот. Поскольку доллар США и юань - это валюты, которые вы не используете взаимозаменяемо, все это может быть строками кода, но подходы, структуры и опыт различаются между различными аспектами. Значительные ошибки, задержки и головные боли ждут любого, кто пытается заставить кодера кодировать то, что он / она не кодирует.
  • Дизайн до того, как писать код - нет ничего лучше, чем заставить работать всю кодовую базу и осознать, что новый дизайн несовместим или требует значительного пересмотра кода.
  • Приступайте к пользовательскому тестированию как можно скорее, потому что пользователи - это те, кого вы не можете контролировать, и они сломают что-то или отвергнут их, а это плохо для бизнеса
  • Устраняйте отрицательные отзывы в приложении, чтобы недовольные пользователи выражали свое недовольство вам, а не широкой публике в магазинах приложений для iOS и Android.
  • Держите одну стабильную ветвь для развертывания, а не несколько «готовых к выпуску» ветвей, которые будут расходиться, а затем запутывать всех и иметь недостающие важные части, на которые у вас уйдет неделя. интегрировать в вашу выпущенную ветку
  • Ведите явный список невыполненных технических задач и планируйте спринты, используя его. Эти вещи имеют свойство терять сознание. Фактически, если вы можете себе это позволить, вы можете даже нанять одного человека для управления этим

 

И это 9 грехов (плюс грехи читателей). Вы бы хотели поделиться с нами подобным опытом? Есть ли другие подводные камни, о которых вы хотели бы предупредить коллег-предпринимателей? Прокомментируйте, пожалуйста, ниже.