Как подготовиться к общению с программистом? часть 1

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

Итак. После того, как вас включили в команду, вам нужно ознакомиться с ТЗ (если оно есть) и понять, какие документы вам нужно будет сдавать. И на первой встрече/созвоне с командой озвучить: «Коллеги, нам по этому проекту нужно сдавать ПМИ (например), т.е. нам нужно заранее понять, как мы результат работ будем показывать заказчику», потому что не для всего может быть интерфейс, работоспособность чего-то можно подтвердить только косвенно или, допустим, в ТЗ могут быть какие-то показатели, о которых разработчик должен знать. Если у вас есть требование, что к сервису должно одновременно 100 пользователей обращаться и он не должен тормозить, то разработчик должен об этом знать. Если в ТЗ написано, что должно несколько графических форматов обрабатываться, то разработчик должен знать, что недостаточно сделать только загрузку файла формата jpeg.

По моему опыту могу сказать, что исходное ТЗ до разработчика часто не доходит, так как задачи для него формирует руководитель проекта или тимлид. Поэтому вы тоже можете быть разработчику полезны, сообщив ему дополнительные сведения или прислав конкретные формулировки из ТЗ. Реализовывать в соответствии с ТЗ или нет – это уже вопрос взаимодействия разработчика со своим руководителем. А вам эту функцию нужно будет описывать в документах.

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

До этого времени можно начинать что-то писать, параллельно прикидывая, что именно вам потребуется от разработчика. Если разрабатывается какой-то продукт, который у вас уже был (какой-то похожий) можно обратиться к старой документации, посмотреть, что написано там и скопировать это в новый документ с пометкой: «В прошлом документе было так». Можно поискать аналогичный документ в интернете. Сейчас часть документов можно подсмотреть в реестре Российского ПО. Если вдруг вы разрабатываете ТЗ, то можно на Госзакупках что-то похожее поискать (какую-то систему похожую). Продолжение следует.