Часто нам приходится сталкиваться не только с техническими, но и этическими вызовами. Что если заказчик просит Вас сделать что-то технически не правильно или даже откровенно ерунду. Как поступить? Сделать, не сделать и оспорить это решение? Как должен поступить профессионал сталкиваясь с такой проблемой?
John Z. Sonmez в своей книге «Soft Skills The software developer’s life manual» размышляет о том, что значит быть профессионалом:
«Один из моих любимых разработчиков софта и авторов Боб Мартин написал отличную статью как говорить НЕТ, которая как раз и посвящена этому вопросу. В этой статье он сравнивает программиста с врачом. Он говорит о том, как нелепо пациенту учить врача делать свою работу. В этом примере пациент говорит о том, что у него болит рука и врач должен отрезать ему руку. Конечно врач говорит «нет» в этом случае. Но во многих подобных случаях программисты, страшась гнева начальства, говорят «да» и выполняют ампутацию своему коду «
Далее Джон также размышляет в подобном ключе. Основная его идея говорить нет даже рискуя потерять работу.
«Это может даже означать, что вы будете уволены, но иногда это цена которую надо заплатить если вы хотите называть себя профессионалом. В краткосрочном периоде это может быть болезненно, но постоянно делать свою работу правильно на протяжении всей карьеры лучше и оправдает себя в итоге в отличии от альтернативного варианта, плюс вы будете спать лучше по ночам»
Мне приходилось часто сталкиваться с таким вопросом, но мое мнение отличается от Джона и Боба.
Во первых, сравнение с врачом это сильное преувеличение просто не уместное в контексте разработки софта. Как правило, заказчик вполне компетентен, чтобы представлять последствия принятых решений. Кроме того, возможности разработки позволяют откатить не обратимые изменения в отличии от отрезанной руки.
Во вторых, быть профессионалом это значит, что работа будет сделана не зависимо от настроения, погоды на улицы, личных проблем и прочего, что не связано с работой. Профессионал всегда делает свою работу и за это ему платят. Говорить «нет» и не делать работу потому, что этого требуют какие-то принципы не профессионально. Так поступают капризные любители.
В третьих, а что если исполнитель просто не знает всех деталей?! Заказчик не обязан раскрывать все свои дальнейшие планы и обстоятельства, приведшие к странному(не правильному) заданию. Что если потребности бизнеса, на текущий момент, не позволяют вкладывать много средств в разработку правильной по всем стандартам функциональности? Программирование стоит дорого. Временные рамки на выполнение задачи вещь не абстрактная и связана с бизнесом напрямую. Зачастую заказывая быстро и не качественно заказчик хочет получить прототип! И уже потом проверив прототип в действии принимать дорогостоящие решения.
На мой взгляд, получив не правильное задание нужно:
- Убедиться, что заказчик осознает неправильность и последствия этого шага. На это не жалко потратить времени. Но именно этот шаг самый важный.
- Четко определить временные рамки задания, наверняка задание срочное, но возможно озвученный дедлайн все таки можно отодвинуть.
- Постараться построить хоть какое-то подобие архитектуры на кривых требованиях. Да, это трудно, но профессионал должен работать и в таких условиях.
- Прокомментировать все костыли и хаки в коде подробно. Именно кривой код наиболее труден для восприятия. Возможно этот код будут поддерживать другие программисты. И они будут посылать лучи поноса в вашу сторону т.к. со стороны будет казаться, что код программировал какой-то мудак. Они же не будут знать всей предыстории.
- Выполнить задание в срок
Вы часто сталкивались с такими заданиями/ситуациями? Как обычно вы поступаете? Если не трудно поделитесь в комментариях своих мнением на эту тему.