Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Никогда не понимал, зачем отрывать программистов от задач и тащить на встречу с заказчиком? Чтоб страдали все?
Есть же менеджеры, которые работают переводчиками между бизнесом и разработчиками, и в курсе, что, как и зачем работает, что улучшилось и почему возникала проблема (уже исправленная), они обычно одевают костюмы вместо удобного дранья для офиса и могут подойти к программистам и попросить в паре слов объяснить всё до встречи.
Есть же менеджеры, которые работают переводчиками между бизнесом и разработчиками, и в курсе, что, как и зачем работает, что улучшилось и почему возникала проблема (уже исправленная), они обычно одевают костюмы вместо удобного дранья для офиса и могут подойти к программистам и попросить в паре слов объяснить всё до встречи.
Таких очень мало на рынке. Меньше, чем программистов на несколько порядков.
Так их и нужно 1-2 на компанию, на несколько порядков меньше, чем программистов.
Это ж не менеджер проекта, это клиентский менеджер.
Приходит клиентский менеджер к ПМ и обсуждает нетехнические детали по проекту. Потом — к клиенту — клиенты тоже не хотят технических деталей, им нужна суть и фичи. Потом, с описанием фич, снова к ПМ, обсудить «а можем ли», дальше — к своему руководству, а-ля «клиенты хотят это и это, мы с ПМ обсудили — это ад и доработки, клиента убедил, он готов продолжить сотрудничество и подкинуть баблишка, берёмся?»
И потом снова к ПМ, после принципиального решения.
В итоге — никто не дёргает программистов, все всё знают, ПМ управляет проектом, а не мотается постоянно по городу на встречи, клиентский работает с заказчиками.
Нет, можно всё это свалить на менеджера проектов — пусть и проект ведёт, и на встречи катается, и всё согласовывает, заодно пусть код рефакторит, стены красит и презентации показывает, но стоит ли?..
PS единственный вариант, когда заказчикам стоит давать контакты разработчиков — когда идёт интеграция / внедрение и нужны быстрые коммуникации и технические детали для обоих сторон. Но там уже разговоры «Я ускорил $FEATURE в десять раз» зайдут на ура.
Приходит клиентский менеджер к ПМ и обсуждает нетехнические детали по проекту. Потом — к клиенту — клиенты тоже не хотят технических деталей, им нужна суть и фичи. Потом, с описанием фич, снова к ПМ, обсудить «а можем ли», дальше — к своему руководству, а-ля «клиенты хотят это и это, мы с ПМ обсудили — это ад и доработки, клиента убедил, он готов продолжить сотрудничество и подкинуть баблишка, берёмся?»
И потом снова к ПМ, после принципиального решения.
В итоге — никто не дёргает программистов, все всё знают, ПМ управляет проектом, а не мотается постоянно по городу на встречи, клиентский работает с заказчиками.
Нет, можно всё это свалить на менеджера проектов — пусть и проект ведёт, и на встречи катается, и всё согласовывает, заодно пусть код рефакторит, стены красит и презентации показывает, но стоит ли?..
PS единственный вариант, когда заказчикам стоит давать контакты разработчиков — когда идёт интеграция / внедрение и нужны быстрые коммуникации и технические детали для обоих сторон. Но там уже разговоры «Я ускорил $FEATURE в десять раз» зайдут на ура.
Потому что программисты им не доверяют, т.к. это «не программист».
И менеджеры им не доверяют, потому что «это не менеджер».
Это опять же вопрос культуры в компании (и, может быть, в стране), а не специальности.
И менеджеры им не доверяют, потому что «это не менеджер».
Это опять же вопрос культуры в компании (и, может быть, в стране), а не специальности.
Это вопрос тех самых soft-skills, которые постоянно ищут у программистов /irony
Если человек может говорить со своми топменеджерами, разработчиками и клиентами на понятном им языке, не переврать и согласовать хотелки всех трёх сторон — вот вам менеджер проектов, цените его и любите, а не вытягивайте странные скиллы из программистов, которые в гробу видали все эти 5 митингов в день в костюмах с кофе-брейками и объяснения архитектуры apache на пальцах при помощи Сэма, Мэри и картиночек — им фичу нужно допилить и подумать над рефакторингом, а не вот это всё.
Если человек может говорить со своми топменеджерами, разработчиками и клиентами на понятном им языке, не переврать и согласовать хотелки всех трёх сторон — вот вам менеджер проектов, цените его и любите, а не вытягивайте странные скиллы из программистов, которые в гробу видали все эти 5 митингов в день в костюмах с кофе-брейками и объяснения архитектуры apache на пальцах при помощи Сэма, Мэри и картиночек — им фичу нужно допилить и подумать над рефакторингом, а не вот это всё.
Нет, я не против, хороший инженер может и дом построить, и трубу подчинить, и кластер пересобрать, и презентацию сделать — но стоит ли?
Это ж типичная задача, типа «стоит ли директору банка красить забор?» (подсказка: не стоит, потому что за 2 часа покраски забора директор банка потеряет гораздо больше незаработанных банком/в банке денег, чем стоил бы вызов профессионального маляра, даже если не учитывать качество работ)
Это ж типичная задача, типа «стоит ли директору банка красить забор?» (подсказка: не стоит, потому что за 2 часа покраски забора директор банка потеряет гораздо больше незаработанных банком/в банке денег, чем стоил бы вызов профессионального маляра, даже если не учитывать качество работ)
По-хорошему конечно не стоит так делать. Единственный момент — недостаток компетенции менеджера (он менеджер все-таки), и потребность в прямом контакте между специалистами клиента и исполнителя.
А зачастую причины в основном две:
1. Абсолютное отсутствие компетенции у менеджера. Это, конечно не во всех случаях проблема, но обычно так и есть.
2. Показать «товар» лицом. Т.к. программист/дизайнер/другой специалист это по сути ресурс, который продают. Типа не индусы код пишут.
А зачастую причины в основном две:
1. Абсолютное отсутствие компетенции у менеджера. Это, конечно не во всех случаях проблема, но обычно так и есть.
2. Показать «товар» лицом. Т.к. программист/дизайнер/другой специалист это по сути ресурс, который продают. Типа не индусы код пишут.
Ну инвалидацию Кеша и именование переменных я узнал. А вот что что такое "ошибки на единицу"?
IndexOutOfRange
например, путаница в условиях выхода из цикла между "<" и "<=", путаница в индексации с нуля и с единицы. В итоге это приводит к тому, что крайний элемент какой-нибудь структуры обрабатывается не так, как все остальные.
Простой пример: вырезание подстроки. Символы считаются от нулевого, а ваш (ну ок, мой, но я верю, что нас таких много) мозг привык считать буквы, начиная с первой. При этом функция substr первым аргументом принимает смещение от начала (считается с нуля), а вторым — длину фрагмента (где длины непустых фрагментов считаются с единицы). В целом, нетрудно промахнуться на один символ.
Еще пример: цикл типа while. Если условие выхода стоит после тела цикла, то тело цикла всегда выполняется хотя бы один раз и можно обработать первый элемент при том, что на самом деле нужно было вообще ничего не обрабатывать. Если же условие выхода до тела цикла, можно случайно сделать цикл, который никогда не доходит до последнего элемента (например, делаете «item = list->getNext()» а в условии выхода — какое-нибудь «false == list->isEndOfList()»).
Простой пример: вырезание подстроки. Символы считаются от нулевого, а ваш (ну ок, мой, но я верю, что нас таких много) мозг привык считать буквы, начиная с первой. При этом функция substr первым аргументом принимает смещение от начала (считается с нуля), а вторым — длину фрагмента (где длины непустых фрагментов считаются с единицы). В целом, нетрудно промахнуться на один символ.
Еще пример: цикл типа while. Если условие выхода стоит после тела цикла, то тело цикла всегда выполняется хотя бы один раз и можно обработать первый элемент при том, что на самом деле нужно было вообще ничего не обрабатывать. Если же условие выхода до тела цикла, можно случайно сделать цикл, который никогда не доходит до последнего элемента (например, делаете «item = list->getNext()» а в условии выхода — какое-нибудь «false == list->isEndOfList()»).
Например, путаница с начальными (в некоторых языках с 1, в некоторых с 0) или конечными (в некоторых языках, опять-таки, последний индекс соответствует количеству элементов, в других — на 1 меньше) индексами массивов
У меня есть несколько знакомых программистов — все обаятельнейшие люди с отличными коммуникативными навыками. Интересно, это исключение, которое подтверждает правило (как раз выше написано, что программистов часто воспринимают как людей со слабыми социальными навыками), или новая тенденция?
Как вариант, те программисты, у которых «отличные коммуникативные навыки» отсутствуют, именно по этой причине не стали вашими знакомыми. Но это, скорее, шутка.
На самом деле, как мне кажется, программистам, как и представителям любой другой социальной группы, проще общаться друг с другом, а не с кем-то еще. Статья-то больше не о том, что надо выйти из кельи и поговорить с живыми людьми, а о том, что общение с людьми других профессий требует адаптации ваших мыслей для аудитории более широкой, чем та, к которой вы привыкли, особенно если вы хотите быть поняты.
Насчет стереотипов, у меня есть версия, что не столько программистам чуждо человеческое общество, сколько они могут достаточно долго без него обходиться (особенно, если им есть чем заняться). Причем неясно, является ли это профессиональной деформацией, или наоборот, человек с подобным характером с большей вероятностью идет в программирование.
На самом деле, как мне кажется, программистам, как и представителям любой другой социальной группы, проще общаться друг с другом, а не с кем-то еще. Статья-то больше не о том, что надо выйти из кельи и поговорить с живыми людьми, а о том, что общение с людьми других профессий требует адаптации ваших мыслей для аудитории более широкой, чем та, к которой вы привыкли, особенно если вы хотите быть поняты.
Насчет стереотипов, у меня есть версия, что не столько программистам чуждо человеческое общество, сколько они могут достаточно долго без него обходиться (особенно, если им есть чем заняться). Причем неясно, является ли это профессиональной деформацией, или наоборот, человек с подобным характером с большей вероятностью идет в программирование.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разговаривать — это трудно. Эссе об общении с непрограммистами