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

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

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

Отсутствие связи

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

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

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

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

Проблемы с доверием

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

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

Один из проектов, над которым я работал, изначально добился больших успехов. Заинтересованные стороны регулярно просматривали код и оставляли отзывы, но в остальном они доверяли разработчикам выполнение работы — и мы это сделали. Дела шли хорошо для обеих сторон. Затем, по мере того как организация нанимала все больше людей с проблемами доверия, один за другим вводились процедуры для «исправления» вещей, которые даже не были сломаны. Петля обратной связи становилась все длиннее и длиннее, пока просто не исчезла. Через некоторое время люди стали задавать больше вопросов о том, как что-то сделать (например, «Как мне выпустить это в производство? Кто должен это подписать?»), а не просто делать это, как раньше. В конце концов, на процедурные вопросы уходило слишком много времени, и все начало разваливаться.

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

Невежество

Невежество — одна из очевидных причин провала проекта, хотя она может быть и не первой в моем списке. Большинство людей понимают это: если кто-то не знает, как выполнить работу, работа не будет выполнена. Или, может быть, они знают, как это сделать, но качество будет низким, и это может занять гораздо больше времени. Большинство людей, в том числе разработчики, не осознают, что между опытным и неопытным (или невежественным) разработчиком этот разрыв может быть в 100 и более раз!

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

Однажды меня наняли для проведения спасательной операции в проекте, который был огромен как по масштабу, так и по количеству наворотов, внесенных предыдущими разработчиками. Первым человеком, которого наняли для его написания, был недорогой разработчик-любитель. Они работали над проектом целую вечность и в конечном итоге сдались из-за отсутствия прогресса. Затем была нанята консалтинговая фирма, которая не знала, что делает. Они взяли неработающее приложение и добавили сверху слои своего неработающего кода. Промыть и повторить. К тому времени, как я попал на проект, проект уже не подлежал ремонту. Было несколько репозиториев git, в каждом из которых вносились несовместимые изменения, развертывание производилось с помощью zip-файлов, отправленных по электронной почте «разработчику devops», который явно не имел права брать на себя столь важную роль, и никто не знал, как найти официальную текущую версию кода. Меня попросили добавить функцию, и я не мог сделать это иначе, как обойдя гнилые части кода и внедрив приложение-паразит, которое стояло рядом с их старой кодовой базой. Они не были заинтересованы в переписывании из-за огромного количества времени, которое они уже потратили на приложение (хотя я подозреваю, что переписывание заняло бы у меня часть времени).

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

Если повезет, невежество может вылечиться до того, как все станет совсем плохо. В конце концов, невежество имеет тенденцию уменьшаться с опытом, пока человек не становится жертвой высокомерия. Но это не всегда работает. С невежеством лучше всего бороться еще до того, как вы наймете. Если вы не знаете, как распознать его самостоятельно, попросите совета у более опытного человека по найму. Хотя они могут не иметь возможности работать с вами, они могут помочь вам в процессе найма. Не полагайтесь на HR-компании и биржи вакансий, так как они не являются экспертами в этой области и не всегда смогут определить неопытного специалиста. Особенно сегодня, когда каждый Джо и его собака могут создать убедительный образ эксперта, который получит множество поклонников в Интернете. Они могут даже выступать на конференциях или издавать книги! Если у вас нет доступа к опытным людям, что ж… удачи вам!

Неумение идти на компромиссы

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

Эта проблема «все является приоритетом», хотя и не является главным пунктом в этом списке, вероятно, является вторым по распространенности фактором после невежества. Обычно проекты какое-то время справляются за счет жертв и уступок, на которые идут люди, работающие над реальными задачами, но это ненадолго. Если линии не нарисованы, все разваливается.

Так было почти во всех компаниях, в которых я работал. Если нет людей, управляющих ожиданиями, дела идут очень быстро. Во-первых, я всегда включаю поправку на «бескомпромиссность» при оценке задач. Каков самый сложный способ, которым вы могли бы это сделать, со всеми прибамбасами, которые только можно пожелать? Используйте эту оценку. А затем настаивать или обещать более простую версию, которая, вероятно, будет достаточно хороша для большинства людей, и просить внести несущественные улучшения в будущую итерацию. Это то, что я называю «управлять ожиданиями». Дело не столько в том, чтобы мало обещать, сколько в том, чтобы быть реалистичным в отношении возможностей и приоритетов.

Привычная сложность

Даже когда мы можем исключить злой умысел, личностные проблемы или невежество, часто всплывает еще одна проблема, и это привычная сложность. Люди иногда делают что-то по привычке, а не для решения реальной проблемы. Они начинают с того, что «все так делают», а затем приобретают привычку делать что-то таким образом, поэтому продолжают делать это, куда бы они ни пошли. Получение особенно высокой компенсации за такую ​​производительность еще больше укрепляет мысль о том, что она «работает» и, следовательно, нам нужно ее больше.

Я не говорю (просто) об использовании сложных инструментов и фреймворков. Я говорю в более общих чертах. Организационные процессы, которые делают противоположное тому, что обещано, методологии, которые не совсем работают, и т. д. Отличное резюме этой проблемы дает Аллен Холуб в своем выступлении Смерть Agile, в котором он называет эти привычные сложности карго-культ.

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

клиентские шлюхи

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

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

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