Николай Товеровский |
Павел! По сравнению с домами и космическими шаттлами, программное обесечение изменять легко и недорого. Если не использовать это преимущество, конкуренты вас обойдут. Так что, конечно, разработка и дизайн должны идти параллельно, постоянно взаимодействуя друг с другом и улучшая финальный продукт. Важен настрой команды. Когда я прошу разработчиков подготовить техническую часть плана проекта, мне часто говорят, что без макетов этого сделать невозможно. Понятно, почему так происходит — люди не любят нарушать обещаний, а последовательная организация этапов проекта даёт ощущение безопасности: разработка начинается, когда макеты готовы и можно оценить трудоёмкость. Однако Правда в том, что разработчикам всегда приходится оценивать работу, исходя из примерного описания задачи. Макеты уточняют описание, но дожидаться их убыточно для бизнеса. Текстовое описание задачи позволяет сделать приемлемую оценку и не ждать дизайнеров несколько недель. Мы применяем принципы Некоторые части программного обеспечения трудно модифицировать. Обычно это сложные механизмы и алгоритмы Коля Митин о разработке бэкенда:
Я подхожу к разработке бэкенда как к разработке АПИ. То есть как к набору функций, который отдаёт данные для построения страниц. В Спецификации — инструмент постановки задачи. Они появляются в момент передачи макетов в работу и детализируют дизайнерские решения. Критически важно, чтобы спецификации написали сами разработчики, так будет соблюдён принцип Дизайнеры готовят статические слепки будущей системы, а разработчики видят всю картину в динамике, поэтому хорошо представляют сценарии, частные случаи. Так что, если при согласовании спецификаций разработчики задают трудные вопросы, а фичи упрощаются и исчезают, значит вы всё делаете правильно. |
P. S. |
Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.
|