Какого роль общения в нашей жизни? Огромна. Мы всегда находимся в общении, разговариваем со своей любимой, умеем слушать книгу и уметь задавать ей правильные вопросы, и я уверен, вы хотя бы раз разговаривали с животным, и самое странное оно же отвечало вам.
Общение это искусство, оно требуется от человека не только речевого аппарата, но и ума, который сможет строить синтаксические конструкции, анализировать собеседника, получать и анализировать ответ.
А какого же роль общения в разработке программного обеспечения?
Всем доброго времени суток!
Прочитав несколько книг по проектированию архитектуры программного обеспечения и получив настоящий опыт разработки в фирме, я бы хотел сформировать несколько советов, фактов для разработки на любом этапе разработке.
Можно выделить три состояния у фактов которые знают люди:
Так вот почти все, факты которые могут поспособствовать в развитии проекта, сделать его в срок и качественно относятся ко второму, и да есть факты и из третьего типа. И тем важнее их узнать и начать выполнять.
Помните ««оптимистичная оценка» является главной причиной разрушения сроков выполнения в 51% проектов.». Оценка делается не вовремя и не теми людьми, будьте реалистами, не гоняйтесь за журавлем в небе, идите на компромиссы с разработчиками.
Так все таки какого же роль общения в разработке программного обеспечения? Общение – король, а ясность и лидерство, его верные слуги.
Общение это искусство, оно требуется от человека не только речевого аппарата, но и ума, который сможет строить синтаксические конструкции, анализировать собеседника, получать и анализировать ответ.
А какого же роль общения в разработке программного обеспечения?
Всем доброго времени суток!
Прочитав несколько книг по проектированию архитектуры программного обеспечения и получив настоящий опыт разработки в фирме, я бы хотел сформировать несколько советов, фактов для разработки на любом этапе разработке.
Можно выделить три состояния у фактов которые знают люди:
- Помним и всегда выполняем
- Знаем, но так редко это можно воплотить в жизнь
- Не знаем
Так вот почти все, факты которые могут поспособствовать в развитии проекта, сделать его в срок и качественно относятся ко второму, и да есть факты и из третьего типа. И тем важнее их узнать и начать выполнять.
- Будучи разработчиком, небольшого модуля, или всей системы, лучший способ донести информацию собрать коллектив в одной комнате и на доске нарисовать то, что вы задумали. При этом не стоит забывать о том, что нужно вести документацию. Но скорее даже заметки о том, почему вы выбрали то или иное решения для архитектуры. Так как. время пролетит, к вам в команду или даже на ваше место придет, кто то другой и ему нужно быть знать, как вы пришли к тому, к чему пришли. Еще один важный момент, даже не занимая должность ведущего разработчика, имея необходимую компетенцию вы не только можете, но и должны быть лидером, чтобы защитить свой выбор, как известно хороших архитектурных решений может быть много.
- Наверное, самой трудно исполнимый совет, т.к. его реализация в коллективе меньше дести человек, и уж тем более один на один несколько не оправдана. Встаньте. И вы будите услышаны. Это все что нужно чтобы привлечь внимание, гул других голосов утихнет, ваш голос изменится тональность и громкость, вы будите чувствовать себя уверенней. Вы сможете наладить визуальный контакт, вы сможете более продуктивно использовать мимику и жесты. Одним словом, встаньте и вас услышат и выслушают.
- Вам кажется, что в вашей работе почти нет общения из второго типа, только «болтовня»? Смею вас огорчить, есть вы, просто не туда смотрите. Почти любая просьба об увеличении зарплаты, мощностей или пересмотра требований и вытекающих сроков разработки, это не просто общение это переговоры. И в них крайне не желательно идти на уступки по первому требованию.
- В разработке нет местоимения «Я». Не позволяйте своему эго поселить вас в замке из слоновой кости и не общаться с простыми смертными программистами.
- Жаргон, профессиональный. Это то, что сделает общение со своими коллегами намного приятнее, насыщенней и ярче. Программисты должны уметь общаться друг с другом ясным, лаконичным и эффективным способом.
- И вот он гигант всех бед программных решений, «Оценка». Анализ требований это не просто переговоры это война, между тремя ненавидящими друг друга расами, «заказчик» — трехглавый змей который не знает чего он хочет и это должно было реализовано вчера, менеджеры которые не в курсе что хочет заказчик и как это вообще может быть реализовано кодом, или еще хуже добавлено к уже существующей архитектуре, и программисты, чья задача сводиться реализации такой архитектуры что ни атаки заказчика ни ветер перемен не сможет ее разрушить.
Помните ««оптимистичная оценка» является главной причиной разрушения сроков выполнения в 51% проектов.». Оценка делается не вовремя и не теми людьми, будьте реалистами, не гоняйтесь за журавлем в небе, идите на компромиссы с разработчиками.
Так все таки какого же роль общения в разработке программного обеспечения? Общение – король, а ясность и лидерство, его верные слуги.