​Как поладить с программистами. 1. Программист — не гадалка. Вот как нужно сообщать о проблеме программисту (и любому другому технарю, который должен вам помочь): — сообщить окружение ПО, где возникла проблема: железо, операционная система, браузер, номер сборки, полное наименование клиента (если это у клиента); — по возможности собрать анамнез: что делали с ПО, что происходило в момент сбоя, были ли проблемы на инфраструктуре, скриншоты ошибок и т.д.; — сообщить о целях и задачах пользователя ПО — возможно, все и всех недопоняли. 2. Излагайте прямо. Если вы внешний или внутренний заказчик, не нужно пытаться написать максимально сложное техническое задание. Назначьте встречу и обговорите свои цели, задачи и требования. Программист сам составит техническое задание и отправит его вам на согласование. 3. Не считайте программиста тупым. Чем проще и профессиональнее вы изъясняетесь, тем быстрее найдете с программистом общий язык. 4. Не ставьте сроки и условия. Работает примерно так: вы рассказываете о содержании задачи, называете желаемые сроки и обозначаете важность задания. Программист оценивает выполнимость, сложность, варианты исполнения, занятость ресурсов и уже отвечает вам, в какие сроки он уложится. И помните: программист никогда не виноват в том, что менеджер не способен адекватно планировать. 5. Не отворачивайтесь от своей же задачи. Если вы полагаете, что на передаче технического задания ваша IT-история закончилась, то вы ошибаетесь. Вы заказчик, у вас требования и именно вы должны оценить проект, а именно протестировать его на промежуточных этапах и в финале, попробовать проект на реальных рабочих средах, попросить своих коллег и подчиненных оценить работоспособность и актуальность релиза, проекта и т.д. 6. Не приходите с ненужными задачами. Перед тем, как обратиться за разработкой к внешнему или к внутреннему разработчику, проверьте, действительно ли вам так нужна фича, функция, сайт или лендинг. 7. Не давите властью. 8. Не косите под программиста. Никакого нокода, псевдокода и прочих UML-диаграмм, если вы досконально в них не разбираетесь. Универсальнее человеческого языка здесь что-то сложно придумать. 8. Не переобувайтесь на ходу. Представим, вы сбили свои планы, круто изменили масштабы проекта, полностью проигнорировали занятость разработчика и вообще не молодец. Так вот если для внешних клиентов есть договор с подписанным ТЗ и его расторжение, то для внутреннего клиента может быть еще и руководитель, который скажет: «Ну а что такого, справишься?» Зная это, постарайтесь продумать масштаб проекта заранее и вносите минимальные, важные для текущей постановки задачи, изменения. Это позволит завершить задачи эффективно и без срыва дедлайнов. Полная версия статьи