Несколько дней назад я разговаривал с коллегой, который изменил мой подход к новым проектам.
Майкл Де Вильдт ( Michael De Wildt ) — бывший старший инженер 99designs, он помогал масштабировать свою инфраструктуру во время их огромного роста. Он также создал успешный плагин для WordPress «Резервное копирование WordPress в Dropbox » с загрузками более 1 млн., А также стал соучредителем компании Influx.com, которая предоставляет обслуживание клиентов как услугу.
Благодаря своему опыту как в области проектирования, так и в сфере бизнеса, он дает довольно редкое понимание разговоров о разработке программного обеспечения. Наше основное внимание было сосредоточено на том, когда что-то спроектировать, а не когда взламывать прототип.
Вот мое признание менеджера по продукту: несмотря на все пользовательские истории, исследования и тестирование, почти невозможно знать, правильно ли вы строите… пока люди не используют его. Ничего страшного. Это честно Глупо притворяться, что сфера действия — это не просто догадка о потенциальном решении. Получение пользователей как можно раньше является ключевым.
Подход Майки — сначала взломай, потом инженер — действительно освежает. Это позволяет лучше понять процесс и требования. «Это прототип, это нормально, если он сломается» против «Это бизнес-требование и функция, которую мы будем поддерживать вечно».
Задача состоит в том, чтобы создать культуру доверия, которая гарантирует, что все в команде понимают ограничения каждого из них. Когда взломанная функция ломается, это ожидается.
Вот несколько цитат, которые попали домой:
Здание против взлома (0:32)
«Вы не строите мост через реку, пока не узнаете, что стоит построить на другой стороне. Инженер придет и построит мост независимо. Хакер сначала пересечет реку, чтобы убедиться, что все в порядке. Так что хороший разработчик программного обеспечения возьмет свою шаткую лодку через реку и убедится, что стоит построить мост ».
О командной работе и доверии (3:56)
«Для того чтобы разработчик мог взломать компьютер, ему нужно довериться — руководителю своего продукта или тому, кто отвечает за руководство бизнесом, — ему нужно верить, что после сеанса взлома ему будет позволено превратить его в мост. Если это доверие нарушено, будет очень трудно заставить инженера взломать снова. Потому что они похожи на «В прошлый раз, когда это произошло, вы просто покинули эту чертову структуру и не позволили мне превратить ее в мост. А теперь посмотри на это.
В масштабе (9:23)
«Со временем, когда команда становится больше, (хакерство) становится все труднее. Когда у вас есть один человек, который знает, что эта часть приложения не очень хорошая … это довольно легко. Когда у вас есть 5, 6, 7 разработчиков, это становится трудным делом ».
Стоит отметить, что такой процесс требует отличного общения и доверия в команде. Если есть низкое доверие и культура вины, это, вероятно, не сработает. Как говорит Agile манифест: индивидуумы и взаимодействия над процессами и инструментами.
Будет ли этот процесс работать для вас? Или хакерство — это то, что происходит на стартапах и сторонних проектах? Я хотел бы услышать, что вы думаете.