Индивидуальный разработчик в стартапе [закрыто]

Все, что вы упомянули, звучит довольно часто в разработке программного обеспечения и / или работе в стартапе (насколько я слышал), не говоря уже о том, чтобы совмещать эти два аспекта и быть единственным разработчиком, которому (по-видимому) некому отчитываться.

Несколько возможных решений:

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

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

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

  Вышеупомянутое может быть трудно сделать, особенно если учесть, что большинство / все люди, поручающие вам эти задачи, вероятно, являются вашими старшими, поэтому вам может понадобиться помощь...

• Иди поговори со своим боссом. Большинство людей поймут и попытаются прийти к какому-то соглашению, которое будет работать для всех. Возможно, они:

  • Дайте вам другого разработчика. Тот же объем работы, вдвое больше рабочих — хороший план.

  • Помогите с некоторыми/большинством/всеми вопросами «Постарайтесь лучше управлять людьми», проведя неформальную беседу с соответствующими сторонами или создав некую формальную структуру для планирования вашего времени (и, возможно, времени других сотрудников в аналогичной сфере). сценарий). Это может включать попытку...

  • Наймите вам менеджера проекта. Скорее всего, это будет кто-то с другими обязанностями (возможно, уже работающий там), так как маловероятно, что кто-то просто будет управлять вашим временем, если только вы не менеджер. В идеале это должен быть кто-то, кто достаточно разбирается в разработке программного обеспечения, поскольку очень и очень распространенная жалоба заключается в том, что другие просто не «понимают» это — они ожидают необоснованных вещей, они не понимают, почему это занимает так много времени и т. д. Наличие кого-то, кто знает деловой жаргон, чтобы объяснить эти вещи в понятных терминах всем остальным, устраняя при этом большинство ваших отвлекающих факторов (поскольку люди должны говорить с менеджером проекта, а не с вами напрямую, чтобы планировать свое время), должно очень помочь.

• Просто держись. Стартапы не остаются стартапами навсегда. Вы определенно можете ожидать долгих часов работы во многих стартапах, но, если компания преуспеет, вы должны пожинать плоды в значительной степени. Я не говорю, что вы также должны работать до смерти — слишком долгая работа в течение продолжительных периодов времени пагубно сказывается на производительности — вам придется выяснить, сможете ли вы найти приемлемый баланс между работой в течение поддерживаемого количества часов и выполнение необходимого объема работы.

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

Разговаривать

Если вы разработчик-одиночка в стартапе, то «управление заинтересованными сторонами» — это совершенно иная ситуация, чем в крупных компаниях. Их не должно быть так много — соберите их в одной комнате и поговорите.

Этот разговор очень важен для компании на данном этапе! Стартапу нужно сделать много технических вещей; и вы (на данный момент) главный двигатель технологического стартапа. Порядок и приоритеты технических проектов — ключевое решение на высшем уровне, которое сильно влияет на всю компанию. «Выполнять все проекты одновременно одинаково» может быть очень глупой стратегией, если вы не можете на самом деле выполнить все проекты.

Оцените, зная ваши обстоятельства

Вы знаете, что у вас есть X параллельных проектов, и вы уже видели, как часто возникают большие объемы немедленных задач по обслуживанию/исправлению ошибок. Если будете делать оценки, имейте это в виду - четырехчасовая задача сегодня вечером не будет сделана, потому что вам нужно закончить текущую задачу, которая продлится до обеда, исправить несколько ошибок, которые займут 0-3 часа, и сделать это. другое задание для того другого проекта, который вы обещали вчера; так что ты даже не начнешь эту четырехчасовую работу сегодня вечером.

привыкнуть к этому

В обозримом будущем окружающая среда будет именно такой. Единственное, что может измениться, — это ваше собственное понимание и понимание ваших товарищей по команде.

Будут эти быстрые изменения требований и отказ от полуфабрикатов; возникнет необходимость быстро оценить (оценить? прототип!) идеи, которых еще час назад не существовало; необходимость делать невозможное как можно скорее; и короткие итерации со многими результатами. Это не изменится. Однако неумение делать все не делает вас плохим работником для этой должности (если только это не сломает вас психологически).

Изменение эффекта

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

Вы можете изменить ожидания — поймите свое время, не обещайте слишком много, не перегорайте и держите других в курсе даже неприятных истин. Если вы пообещали, что X будет сделано завтра, но более важные дела отнимут у вас сегодня, завтра и послезавтра — ничего страшного; в стартапе все будут (должны?) знать эти другие вещи и понимать их; но вы должны держать их в курсе, что на самом деле X не будет сделано, чтобы они могли соответствующим образом перепланировать. Это ожидаемо - точно так же, как вам приходится менять планы, поскольку требования постоянно меняются, они, вероятно, привыкли делать то же самое.

Вы можете изменить способ своей работы — «двигаться быстро и ломать вещи» — стиль работы, сильно отличающийся от стиля «трижды проверять каждый результат на наличие опечаток»; в стартапе может быть выгодно (и необходимо) пожертвовать качеством, чтобы выиграть время. Часто бывает достаточно самого минимального прототипа, скрепленного веревкой и жевательной резинкой. Технический долг может быть настоящим бременем, но иногда разумной стратегией является сознательное взятие на себя технического долга — есть много успешных стартапов, которым нужно было выбросить и заменить ужасный код + системы, которые у них были изначально; но они не добились бы успеха, если бы потратили время на то, чтобы построить их должным образом с первого раза.

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

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

Вы можете попытаться разбить на модули все, что вы делаете, и построить для повторного использования, и тщательно задокументировать это. Когда менеджеры или клиенты приходят к вам и просят много функций, вы должны уметь сказать «нет». Я знаю, что вы чувствуете, что вам нужно угодить всем, но вы не должны быть на 100% гибкими при реализации новых функций, которые не были тщательно продуманы. В долгосрочной перспективе это повлияет на продукты, над которыми вы работаете.

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

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

Надеюсь это поможет. :)

То, что я описал выше, нормально?

Да. Очень. Одной из больших проблем разработки программного обеспечения (и разработки вообще) является определение разумных оценок времени для рабочих запросов. Тесное сотрудничество с заинтересованными сторонами для согласования разумных ожиданий.

Как я могу управлять ситуацией, чтобы все остались довольны?

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

Вот что, на мой взгляд, вам нужно сделать:

Документируйте все.

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

По моему опыту, это, безусловно, самая важная часть этого процесса. Я понимаю, что людям, не являющимся техническими специалистами, не всегда будет приятно собираться с вами, чтобы заранее решить, какие кнопки должны быть на странице или что-то в этом роде ("это ВАША работа!"), но, по крайней мере, тот факт, что вы разместили этот документ вместе означает, что позже, когда ваш клиент скажет вам, что он хочет добавить функции X, Y и Z, вы можете сказать ему: «Хорошо, конечно, я могу это сделать, но это приведет к тому, что этот продукт займет [количество время] дольше развиваться.

Ах да, а когда эти функции добавятся? Внесите их в дизайн-документ и попросите клиента подписать изменения.

Я понимаю, что как разработчик это похоже на много дополнительного времени на то, что на самом деле не является программированием и, следовательно, не кажется ни продуктивным, ни веселым, но посмотрите на это так: ваш проектный документ будет служить чем-то вроде схемы книга, которую вы собираетесь написать. Никто не собирается «читать» книгу в классическом смысле этого слова, но они будут ее использовать, и важно точно знать, о чем будет эта книга, прежде чем вы начнете ее писать.

Обеспечить результаты, как только вы можете.

Я имею в виду не то, что вы должны придерживаться расписания, потому что, конечно же, вы этого хотите (и, судя по всему, это в любом случае может быть непросто). Я имею в виду, попробуй и получи что-нибудьвашему клиенту, чтобы он мог просмотреть и утвердить / запросить изменения так быстро, как вы можете. Например, если вы разрабатываете веб-страницу или приложение WPF, как можно скорее получите их каркас. По мере того, как вы подключаете его и добавляете функции, представляйте их своему клиенту, как только вы их закончите, чтобы они могли их протестировать (предостережение: некоторые люди просто не будут тестировать материал, пока он не будет запущен или не собирается, так что не полагайтесь на это, однако вы можете использовать это как возможность сказать: "Я представил вам функцию X 3 недели назад. Я точно могу изменить способ ее работы, но это займет X дополнительного времени".

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

Меня немного удивляет, когда разработчики делают это, и я не говорю, что вы это сделаете, но нужно сказать: время для рефакторинга кода наступает всякий раз, когда у вас есть шанс, время для редизайна наступает всякий раз, когда клиент запрашивает что-то, что вы не можете предоставить в текущем дизайне, и время для тестирования всегда, когда вы программируете. Я понимаю, что этот метод может создавать спагетти-код, но именно поэтому вы проводите рефакторинг.

Кроме того, если вы единственный разработчик в своей компании, ваши коллеги/клиенты не будут знать, что такое «процесс разработки». У них будут требования, которые они хотят, чтобы вы выполнили. Иногда они понимают на полпути к выполнению работы, что требование, которое они вам дали, должно быть более надежным, или что то, как вы решили проблему, создает нефункциональные проблемы, которые они не озвучили вначале.

Никогда не говорите: «Я не могу.

Ну, я думаю, если они хотят, чтобы вы сами разработали новую версию Call of Duty за 2 недели, вы можете сказать, что не можете сделать это за такое количество времени. Но я имею в виду следующее: если ваши клиенты/коллеги дают вам какую-то функцию, не говорите им, что это невозможно сделать. Если это будет сложно внедрить в ваш существующий дизайн, сообщите им, что вам нужно будет немного реорганизовать и что это займет больше времени (постарайтесь указать точное время - если вы переоцените или недооцените, вы всегда можете скорректировать это позже). Если вы буквально не знаете, как что-то сделать, сообщите, что вам нужно изучить решение, и что вы дадите им оценку добавленного времени в течение дня или двух. Если есть физические ограничения, мешающие вам делать то, что они хотят, или если то, что они хотят, нарушает какой-то другой принцип («Эй,

Постоянно общайтесь.

Если вы можете справиться с этим, короткие 10-15-минутные ежедневные встречи в стиле «схватки», на которых вы вкратце обсуждаете, над чем работаете, и, возможно, получаете некоторые незначительные разъяснения, хороши даже для не-разработчиков. Я знаю, что иногда вы можете попасть в этот «ад совещаний», когда вы тратите больше времени на разговоры с людьми о том, что они хотят, а не на то, чтобы предоставить им это, но в целом я думаю, что программисты склонны ошибаться в сторону опускания головы. и просто делать что-то, так что неплохо было бы, возможно, подтолкнуть себя к постоянной проверке со своими заинтересованными сторонами.

По крайней мере, еженедельное или два раза в неделю собрание, на котором вы рассказываете о том, что уже сделали, и обсуждаете предстоящие задачи, должно привести к нескольким вещам:

1. Это поможет вам развить свои собственные коммуникативные навыки (не сказать, что вы уже не умеете общаться, но это то, над чем все разработчики могут и должны работать).

2. Это придаст вашему клиенту/коллегам уверенность в том, что а. вы знаете, что делаете и б. вы понимаете их потребности.

3. Если вы в чем-то отстаете или внезапно возникает необходимость серьезного изменения, вы и ваш клиент/коллеги не будете чувствовать себя ошеломленными этим.

Во всяком случае, это то, что у меня есть. Смотрите на это как на вызов и возможность, а не как на что-то, что обязательно заставит вас рвать на себе волосы. Работа с неподготовленными людьми может быть проклятием (иногда они просят вас сделать что-то почти невозможное и не понимают, почему вы не можете просто сделать это), но также и благословением (иногда самое маленькое дополнение, которое потребовалось вы все 5 минут на программирование можете заставить вас чувствовать себя и выглядеть настоящим героем).

Здесь есть несколько отличных ответов об управлении требованиями, но я также хотел бы подчеркнуть, что вам придется управлять собой, а также вашими заинтересованными сторонами.

Например, работа по выходным не является решением даже в относительно краткосрочной/среднесрочной перспективе. У Дэна Кука есть отличное резюме исследования продуктивности в Rules of Productivity Presentation . TL;DR резюмируется на графике на этой странице и говорит, что 40 часов в неделю являются оптимальными для долгосрочной производительности: требуется всего месяц по 60 часов в неделю, прежде чем усталость будет стоить вам дополнительной производительности (и вы работаете 60 часов в неделю, чтобы получить 40 рабочих часов), и в следующие 4 недели вы теряете столько же продуктивности, сколько и прибавили за первые 4.

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

Исполнение, успешный запуск - это N% идеи и (100-N)% исполнения , т.е. ваше предположение об изучении нового было вообще неверным.

New Stuff, вы, по-видимому, работаете над чем-то новым, поэтому предположение о существующих фреймворках и т. д. также весьма ошибочно.

Бизнес, запуск обычно определяется как попытка найти воспроизводимую и масштабируемую бизнес-модель . То есть дело не в вашем коде или даже в том, кто его кодирует, дело даже не в том, что он делает, а в том, как он получен, как он вписывается (в идеале разрушает) в существующую экосистему.

Адаптируйся! Наконец, чтобы быть успешным стартапером, вы должны адаптироваться, вы должны предвидеть необходимые усилия разработчиков и переключиться с роли разработчика, скажем, на HR, чтобы найти несколько хороших программистов , или на менеджера, который будет присматривать за младшими разработчиками и стажерами, или на аутсорсинг. специалист, если часть кода выполняется за пределами предприятия, или системный администратор, если требуется, или представитель для продвижения вашего стартапа на конференции.

Надеюсь, вы владеете долей в этой компании в соответствии с тем, что вы являетесь одним из основателей или 1-м сотрудником, единственным разработчиком или техническим директором (ваш пост не указал). Пожалуйста, проверьте , так ли это, и если нет, попросите основателей скорректировать ваше финансовое положение. Если они терпят неудачу, уходите как можно скорее.

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

Чувак, этот пост навевает воспоминания о прошлых работах. Становится все сентиментальным.

Если у меня есть один совет, он таков: ПРИОРИТЕТ. Большая часть того, что люди хотят от вас, просто не будет выполнена; в сутках так много часов и только один из вас. Расставьте приоритеты и работайте над самыми важными вещами в первую очередь — над проектами, которые получат наилучшее соотношение возврата к затраченному времени.