Комментарии 68
Последний абзац навеял:
Такой шум из-за JPEG, как будто там повсюду капчи.
Не знаю завидовать или нет таким компаниями и менеджерам…
Вообще странно было бы увидеть в частной компании такой расклад, если владельцы сами себе не враги. Регулярно читаю про Хабре про такие крайности, но за свою карьеру не видел (работаю в сфере производства, а не IT). На государственных предприятиях — сколько угодно, сидят целыми Пентагонами.
У нас как-то так (только у менеджера яма в два раза больше и лопат две):
Вообще странно было бы увидеть в частной компании такой расклад, если владельцы сами себе не враги. Регулярно читаю про Хабре про такие крайности, но за свою карьеру не видел (работаю в сфере производства, а не IT). На государственных предприятиях — сколько угодно, сидят целыми Пентагонами.
У нас как-то так (только у менеджера яма в два раза больше и лопат две):
недавно я видел анекдот-историю про разработку. Мол за границей берут 7 программистов и 1 менеджера. А у нас 7 менеджеров и 1 программиста, которых потом заменили на программиста, менеджера, бизнес-аналитика и тому подобное. Не могу найти, может завалялось у кого?
Вот эта, видимо.
Вася плохо поддается мотивации. У него нет склонностей к обучению и командному духу!
Именно! Огромное спасибо!
— Сколько человек здесь работает?
— С бригадиром — 10.
— А без бригадира?
— А без бригадира вообще никто не работает.
PS. До того как проработать программистом 10 лет, я 4 года работал строителем, это один из моих любимых анекдотов тех времен…
— С бригадиром — 10.
— А без бригадира?
— А без бригадира вообще никто не работает.
PS. До того как проработать программистом 10 лет, я 4 года работал строителем, это один из моих любимых анекдотов тех времен…
Метко (плюсую в уме, потому как в реале пока не дорос)!
Излишком мотивации работники, я думаю, ни в одной стране не страдают. Поэтому меня всегда веселят посты — «нафиг нам менеджер, он дебил, мы сами сплошь гасконцы». А дай такому Д'Артаньяну поработать в режиме самоуправления, он своих коллег возненавидит за 2-3 дня. Сколько контор в мире успешно работают по такому принципу? Два-три десятка? Ясно, что к этому нужно стремиться, я обеими руками за, но где взять нанимателям таких работников и где взять работникам таких (умных / глупых) нанимателей?
Излишком мотивации работники, я думаю, ни в одной стране не страдают. Поэтому меня всегда веселят посты — «нафиг нам менеджер, он дебил, мы сами сплошь гасконцы». А дай такому Д'Артаньяну поработать в режиме самоуправления, он своих коллег возненавидит за 2-3 дня. Сколько контор в мире успешно работают по такому принципу? Два-три десятка? Ясно, что к этому нужно стремиться, я обеими руками за, но где взять нанимателям таких работников и где взять работникам таких (умных / глупых) нанимателей?
— Сколько человек здесь работает?
— С бригадиром — 10.
— А без бригадира?
— А без бригадира вообще никто не работает.
У вас было 7 бригадиров и 1 строитель?
У меня трудовой стаж лет 17 наверное, я трудился в разных организациях на таких должностях, как каменщик, завскладом, бухгалтер-оператор, программист, но такого уровня бюрократии, о котором Вы спрашиваете не встречал нигде. Всем понятно, что анекдоты и смешные истории многое утрируют, поэтому надеюсь, что Ваш вопрос несерьезен.
У меня есть пример, когда на одном проекте на каждого программиста было около полутора менеджеров. Так что картинка имеет смысл ;)
Нет, конечно в затронутой теме смысл есть, но не в таких масштабах. Я, кстати, последние два года работаю в отделе, занимающемся разработкой и поддержкой двух критичных гос. систем, и у нас соотношение сотрудников один-к-одному:
1 Начальник
1 Аналитик/Делопроизводитель
1 Разработчик/Архитектор
1 Админ/Консультант (поддержка пользователей)
И, что интересно, при наличии очень разнообразных задач разработки (от правки багов до смены технологий и бизнес-процессов), при таком соотношении сотрудников всё как-то тихо-мирно. Более того, начальник на работе задерживается практически каждый день, а я, разработчик, работаю всегда строго 40 часов в неделю.
Так подумать, может в каких-то случаях и правда начальников побольше нужно, а то они, бедняги, как-то не справляются…
1 Начальник
1 Аналитик/Делопроизводитель
1 Разработчик/Архитектор
1 Админ/Консультант (поддержка пользователей)
И, что интересно, при наличии очень разнообразных задач разработки (от правки багов до смены технологий и бизнес-процессов), при таком соотношении сотрудников всё как-то тихо-мирно. Более того, начальник на работе задерживается практически каждый день, а я, разработчик, работаю всегда строго 40 часов в неделю.
Так подумать, может в каких-то случаях и правда начальников побольше нужно, а то они, бедняги, как-то не справляются…
Ого, у вас жизненный путь однако! Не хотите написать пост об этом? Думаю было бы многим интересно.
У меня на данный момент трудового стажа лет 12, но работать приходилось с очень многими организациями. Как и писал выше, такую бюрократию видел только на государственных предприятиях. Рекордное соотношение наблюдал на одном хрустальном заводе — 2 ИТРа на одного работника. Завод, естественно, почти мёртвый. В Беларуси таких много — и не живут и умереть им не дают (бояться народ без работы оставлять). Предприятия — зомби.
Но что бы у частника — никогда не видел ничего подобного.
А вот отдельных ленивых менеджеров, из-за которых создаётся впечатление «чугунной» бюрократии видел много. Многие, наверное, сталкивались. Вроде конторка маленькая, буквально пару человек, а работать с ними ну просто никак.
У меня на данный момент трудового стажа лет 12, но работать приходилось с очень многими организациями. Как и писал выше, такую бюрократию видел только на государственных предприятиях. Рекордное соотношение наблюдал на одном хрустальном заводе — 2 ИТРа на одного работника. Завод, естественно, почти мёртвый. В Беларуси таких много — и не живут и умереть им не дают (бояться народ без работы оставлять). Предприятия — зомби.
Но что бы у частника — никогда не видел ничего подобного.
А вот отдельных ленивых менеджеров, из-за которых создаётся впечатление «чугунной» бюрократии видел много. Многие, наверное, сталкивались. Вроде конторка маленькая, буквально пару человек, а работать с ними ну просто никак.
Ого, у вас жизненный путь однако! Не хотите написать пост об этом?
Да уж, кому ни говорю об этом, все удивляются, наверное стоит когда-то написать…
такую бюрократию видел только на государственных предприятиях
Полностью согласен, на них склонность к бумагомаранию гораздо выше. В коммерческих конторах, начиная со среднего размера тоже появляется бюрократия, но там обычно пытаются сделать с умом и пользы от от нее больше, чем вреда. А вот гос. сектор зазеркалье какое-то, такое впечатление что любыми способами делают все возможное для снижения производительности и удовлетворенности от работы. Как в анекдоте про армию: мне не надо чтобы быстрее, мне надо чтобы задолбался…
2 ИТРа на одного работника
Думаю, такая ситуация на противоположных концах организации труда на пром. предприятиях: с одной стороны такие вот умирающие заводы, с другой стороны высокотехнологичные производства, где множество выполняемых задач автоматизированы/роботизированы.
>Просто он решает такие задачи, которые вы вместе, пока, не сможете решить за любое отведенное вам время
А можно пример хотя бы одной такой задачи?
А можно пример хотя бы одной такой задачи?
Ну, например, написать JCA-адаптер к унаследованной системе.
Оставить пункт 5, остальное вычеркнуть.
Но я еще ни разу не встречал, чтобы в вузах учили работать работу.
Там как раз именно этому и учат. Никогда не анализировали, чем сотрудник без вышики отличается от сотрудника с вышкой. Ну кроме псевдо-знаний которые сами по себе довольно редко используются.
В наших вузах только этому и учат, потому как в IT у нас курсы 30ти летней давности если не больше (если вы скажете, что я ошибаюсь, то я буду несказанно рад).
Просто работать начинаешь как надо уже после 25ти где-то — студент или выпускник который изначально может пройти все и сделать все как надо уже странный. Кровь там бурлит иначе — молодые они еще. Прорыв сделать — да, изобрести что-то да, всех взбаламутить — да. Но сделать работу от а до я — нет.
На мой взгляд пункт 2 весьма спорный. Обычно когда говорят «Для решения этой задачи мне потребуется 8 часов» — 8 часов это мат. ожидание времени завершения работы. А дисперсия варьируется в зависимости от квалификации разработчика и сложности задачи. По сути это тоже самое что и «от 4 (быстрее точно не смогу) до 16 часов (скорее всего, точно сделаю)», но только оперировать удобнее (хотя наверное это тоже субъективно).
Обычно оценка трудоемкости имеет плотность распределения вероятности с длинным правым хвостом. Длина хвоста пропорциональна неопределенности в задаче. А где неопределенность, там риски. Мне как руководителю, надо знать риски, чтобы адекватно ими управлять.
Ну вот длинный правый хвост — это либо недостаточно декомпозированная задачи, либо просто не верно данная оценка. И то и то зависит от квалификации разработчика. Да, конечно есть вероятность наткнуться на что то из ряда вон выходящее, что очень сильно может затянуть срок, но это не учитывается и верхней оценкой «скорее всего, точно сделаю».
А вы не учитываете, что чаще всего специалисты не идеальны, а задачи им ставят те, с которыми они ранее дел не имели? Точнее, с элементами, с которыми они не имели дела ранее. Соответственно, определить время необходимое на реализацию проблематично.
Конечно, можно заложить увеличение времени на знакомство с новыми вещами, но это все равно работает далеко не всегда.
Самая точная оценка времени необходимого на реализацию задачи — после фактического выполнения задачи.
Конечно, можно заложить увеличение времени на знакомство с новыми вещами, но это все равно работает далеко не всегда.
Самая точная оценка времени необходимого на реализацию задачи — после фактического выполнения задачи.
Учитываю. Но как это расходится с тем что я написал выше? Я говорю о том что оценка от и до — это тоже самое, что и оценка мат. ожидания + дисперсии. И точно так же как вы можете ошибиться в оценках от и до.
Если определить время проблематично, то скорее всего дело либо в том что не ясно как делать задачу, либо она слишком объемная и её нужно разбивать на более мелкие. В первом случае обычно ставят задачу на оценку непонятной задачи. Там уже и пути её решения уточняются, и время выполнения.
Фактическое время выполнения это, конечно, оценка очень точная, только вот никому не нужная. Потому что это уже не прогноз, а констатация факта.
Если определить время проблематично, то скорее всего дело либо в том что не ясно как делать задачу, либо она слишком объемная и её нужно разбивать на более мелкие. В первом случае обычно ставят задачу на оценку непонятной задачи. Там уже и пути её решения уточняются, и время выполнения.
Фактическое время выполнения это, конечно, оценка очень точная, только вот никому не нужная. Потому что это уже не прогноз, а констатация факта.
Задача на оценку непонятной задачи, конечно, позволит более точно спрогнозировать время, необходимое на выполнение основной задачи. Но вот избавиться от длинного правого хвоста поможет далеко не всегда. Да, хвост можно серьезно уменьшить, но избавиться от него (точнее, от его увеличенной длины) получается не так часто, как хотелось бы.
>>выбор длины переменной целого типа есть элемент проектирования
Да, это, безусловно, важнейшая задача, я бы сказал: краеугольный камень преткновения!
А уж в вашем случае(java ecли я правильно понял) — так вообще…
Да, это, безусловно, важнейшая задача, я бы сказал: краеугольный камень преткновения!
А уж в вашем случае(java ecли я правильно понял) — так вообще…
Я наблюдал более чем полутора-часовой спор «а что нам взять для id элементов, integer обычный или long».
И было бы смешно, если бы я не был одним из участников проекта, на котором подобные вопросы встают каждые 3 дня.
И было бы смешно, если бы я не был одним из участников проекта, на котором подобные вопросы встают каждые 3 дня.
Коллегам из СКБ Контур привет!
Знаю, уважаю!
Знаю, уважаю!
Отсюда вытекает восьмой необходимый навык — «умение вовремя обратиться к старшему товарищу (например, к менеджеру) для снижения затрат времени на решение вопросов, которые, по сути, не должны отнимать много времени».
То есть, если за 10-15 минут не смогли решить, какой тип выбрать — пошли к старшему, обрисовали суть вопроса, привели доводы и он вам сказал, как сделать.
Конечно, время старшего дороже и отвлекать его по пустякам нежелательно, но ведь и тратить полтора часа двух (или более) человек на то, что можно решить за 10 минут — часто еще хуже.
То есть, если за 10-15 минут не смогли решить, какой тип выбрать — пошли к старшему, обрисовали суть вопроса, привели доводы и он вам сказал, как сделать.
Конечно, время старшего дороже и отвлекать его по пустякам нежелательно, но ведь и тратить полтора часа двух (или более) человек на то, что можно решить за 10 минут — часто еще хуже.
И это между прочим не смешно. Это реальная проблема. Некоторые граждане заложили в своей системе обмен данными с точностью до 9 знака после запятой, а у нас (по-моему, по закону или какой-то иной нормативе) было 15. Ну и плясали вприсядку при подключении к их обмену фин. данными. Кстати, даже вроде и не подключились в итоге.
Надо было им про guid рассказать: глядишь — и до драки дело дошло бы. :)
6 пункт — это палка о двух концах. Да программисту видней, как работает его код, он его видит насквозь и-и-и… не делает тех действие, которые могли бы привести к ошибке. Все его действия подчиняются тому сценарию, который он разрабатывал, чем объемнее задача или растянута по времени, тем больше «замыливается глаз».
«Замыливается глаз» — это от неправильной мотивации. Когда я в ЦУПе начинал программировать такой профессии — тестировщик вообще не было. Но была персональная ответственность за код, вплоть до статьи УК «халатность». И если коллега находил в моей программе баг, я ставил ему коньяк.
А де пункт «быть мотивированным искать лучшие решения, не ограничивать себя границами заданными тз и областью знаний, уметь проводить R&D когда нужно»? Или вы только code-monkey под TDD и таски из таск трекера учите? Junoir от senior'а отличается только мудростью и тем что последний может нафиг послать и за пару дней предложить решение в таком виде о котором заказчик и все сотрудники раньше и не слышали.
Очень часто я наблюдаю у хороших специалистов тупо страх перед новыми вещами за ихней областью знаний. Если сразу не вдолбить что это плохо — получите программистов которых никогда и не взяли бы в гугл\фейбсук и тд =)
Очень часто я наблюдаю у хороших специалистов тупо страх перед новыми вещами за ихней областью знаний. Если сразу не вдолбить что это плохо — получите программистов которых никогда и не взяли бы в гугл\фейбсук и тд =)
> получите программистов которых никогда и не взяли бы в гугл\фейбсук
А зачем где-либо кроме гугла и фейсбука нужны программисты, которых взяли бы в гугл и фейсбук?
Крайне специфичные компании с крайне специфичным подходом к большинству задач.
Таких компаний на весь мир штук дцать, и в них работает считанная пара процентов программистов, правый хвост нормального распределения.
Для решения типовых задач в типовых проектах (которых 95%) такие программисты не нужны.
Максимум один-два на отдел из 15-30 человек.
А зачем где-либо кроме гугла и фейсбука нужны программисты, которых взяли бы в гугл и фейсбук?
Крайне специфичные компании с крайне специфичным подходом к большинству задач.
Таких компаний на весь мир штук дцать, и в них работает считанная пара процентов программистов, правый хвост нормального распределения.
Для решения типовых задач в типовых проектах (которых 95%) такие программисты не нужны.
Максимум один-два на отдел из 15-30 человек.
Ну, если это окупается с точки зрения трудозатрат и сроков. Тогда, конечно, ДА! Но, бывает, что это не от стремления сделать лучше и больше, а просто следование методологии Resume Driven Development (RDD). Тогда, конечно, НЕТ!
Насчет пункта номер 3: предпочитаю для «мутного» места бросить заглушку и реализовать пресловутые 80% задачи, которые дело техники, чем сразу сесть за подзадачу, которая в итоге может растянуться на все запланированное время, причем без гарантии, что она вообще будет решена.
А в идеале, конечно, исследование «мутных» подзадач лучше выносить в отдельные задачи, чтобы на синтетических примерах превратить их в дело техники)
А в идеале, конечно, исследование «мутных» подзадач лучше выносить в отдельные задачи, чтобы на синтетических примерах превратить их в дело техники)
Помоему это требования к лидам.
Большая часть пунктов достаточно спорна и зависит от проекта.
Далеко не все задачи требуют проектирования. Иногда нужно просто взять и захотфиксить баг. Или решить какую-то research задачку, для которой код пишется один раз.
Такое возможно если все задачи однотипные. А если задача новая (которую ты и, возможно, никто в твоей организации ещё не решал) и отчасти включают в себя research, отчасти разработку прототипов и эксперементирование)? И даже банальные задачи, которые заказчику кажутся простыми могут натолкнуться на непредвиденные препятствия, вроде необходимости рефакторить систему, потому что дальнейшее накопление технического долга слишком дорого.
Тоже самое что и предыдущий пункт. По графику может работать только сферический программист в идеальном вакууме. На практике всегда что-то пойдёт не по плану. Это не значит что планировать не нужно совсем. Но если задавать строгий график то ты в него не уложишься с вероятностью ~99%.
Всё равно что «Соблюдать синтаксис языка». Если не соблюдаешь синтаксис — пошлёт компилятор. Не соблюдаешь стандарты — пошлёт code-review.
Пожалуй, единственный важный пункт. Умение находить золотую середину между стоимостью (временем) разработки конкретной фичи и профитом, который она даст (качеством, требованиям заказчика, etc.). Очень мало программистов могут в этом месте принять объективное решение. Часть скажет что задача сложная и её делать дорого, хотя на самом деле им просто влом разбираться в (новой технологии / чужом коде / etc.). Часть наоборот — скажет что лёгкая и будет потом ковыряться, хотя оно того не стоит. Часть для лёгкой задачи выберет не самое тривиальное решение или наоборот (вместо использования технологии X навелосипедить там где не надо / вместо небольшого трёхстрочного велосипеда заиспользовать технологию X потому что она крутая и интерестно с ней разобраться).
Комитить код, не протестировав его не разу — как минимум странно. А заниматься всесторонним ручным тестированием своего кода, если ты не тестер — не рационально. Лучше юнит-тестов написать.
Если под дефектами подразумеваются баги, а под анализом — их фиксинг — тогда ещё один очевидный пункт. Отклонения от графика возникают не на пустом месте, а являются следствием принятий решений, описываемых в пункте 5. При возникновении непредвиденных сложностей всегда есть два пути — не пилить эту фичу или увеличить сроки.
Проводит декомпозицию задачи и проектирует ее решение
Далеко не все задачи требуют проектирования. Иногда нужно просто взять и захотфиксить баг. Или решить какую-то research задачку, для которой код пишется один раз.
Адекватно оценивает затраты на выполнение
Такое возможно если все задачи однотипные. А если задача новая (которую ты и, возможно, никто в твоей организации ещё не решал) и отчасти включают в себя research, отчасти разработку прототипов и эксперементирование)? И даже банальные задачи, которые заказчику кажутся простыми могут натолкнуться на непредвиденные препятствия, вроде необходимости рефакторить систему, потому что дальнейшее накопление технического долга слишком дорого.
Планирует свою работу и составляет график
Тоже самое что и предыдущий пункт. По графику может работать только сферический программист в идеальном вакууме. На практике всегда что-то пойдёт не по плану. Это не значит что планировать не нужно совсем. Но если задавать строгий график то ты в него не уложишься с вероятностью ~99%.
Соблюдает принятые стандарты
Всё равно что «Соблюдать синтаксис языка». Если не соблюдаешь синтаксис — пошлёт компилятор. Не соблюдаешь стандарты — пошлёт code-review.
Обеспечивает требуемое качество, минимизируя затраты и риски
Пожалуй, единственный важный пункт. Умение находить золотую середину между стоимостью (временем) разработки конкретной фичи и профитом, который она даст (качеством, требованиям заказчика, etc.). Очень мало программистов могут в этом месте принять объективное решение. Часть скажет что задача сложная и её делать дорого, хотя на самом деле им просто влом разбираться в (новой технологии / чужом коде / etc.). Часть наоборот — скажет что лёгкая и будет потом ковыряться, хотя оно того не стоит. Часть для лёгкой задачи выберет не самое тривиальное решение или наоборот (вместо использования технологии X навелосипедить там где не надо / вместо небольшого трёхстрочного велосипеда заиспользовать технологию X потому что она крутая и интерестно с ней разобраться).
Выполняет тестирование и отладку кода
Комитить код, не протестировав его не разу — как минимум странно. А заниматься всесторонним ручным тестированием своего кода, если ты не тестер — не рационально. Лучше юнит-тестов написать.
Анализирует найденные дефекты и отклонения от графика
Если под дефектами подразумеваются баги, а под анализом — их фиксинг — тогда ещё один очевидный пункт. Отклонения от графика возникают не на пустом месте, а являются следствием принятий решений, описываемых в пункте 5. При возникновении непредвиденных сложностей всегда есть два пути — не пилить эту фичу или увеличить сроки.
Соглашусь. Перечисленные компетенции отражают «звезд», не верю, что отбирают только таких, конечно, если не создают уникальные продукты, где большой формат творчества и науки. Хотелось бы верить, что в системных интеграторах работа поставлена на поток, а не изобретение нового решения для нового заказчика, в этом случае — проблемы с организацией потока.
У вас, имхо, немного устаревшие представления об интеграторах. Они уже давно основные деньги зарабатывают не на поставке и наладке оборудования, а на услугах. Одна из таких услуг — разработка ПО, которой мы занимаемся. Поверьте, разработка программной системы федерального масштаба, в которой будут работать более 100 тыс. пользователей и выполнять тысячи специфических технологических процессов — задача не тривиальная. И прежде чем поставить разработку «на поток», требуются глубокие исследования в ходе проектирования архитектуры и ее обоснования.
Есть конечно и рутина. Например, запрограммировать 100500 отчетных форм. Поэтому мы набираем и гуру, и студентов. Работа найдется каждому.
Есть конечно и рутина. Например, запрограммировать 100500 отчетных форм. Поэтому мы набираем и гуру, и студентов. Работа найдется каждому.
При возникновении непредвиденных сложностей всегда есть два пути — не пилить эту фичу или увеличить сроки.
А почему Вы не рассматриваете третий путь — выпить чаю/кофе/минералки и подумать?
По наблюдениям, часто как раз этот вариант и спасает от слива полимеров (сроков, функционала, качества, душевного равновесия). Хотя у юниоров и специалистов вне зоны своей компетенции — да, проблема подумать о чем-то наперёд, когда понаделанное позади внушает суеверный трепет при чуть менее чем полном отсутствии понимания… Но на то и способность учиться)
Не вижу связи между заключением статьи и навыками сферического программиста в вакууме
Не хочется быть занудой и сильно офтопить, но цитата «Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live» на самом деле принадлежит не Макконелу, а John Woods либо Martin Golding.
Ответ «Для решения этой задачи мне потребуется 8 часов», — неправильный. Оценка всегда величина вероятностная. Правильный ответ, например, «от 4 (быстрее точно не смогу) до 16 часов (скорее всего, точно сделаю)». Большой разброс не должен смущать руководителя, он отражает высокий уровень неопределенности при решении программистских задач.
Мне кажется, что тут скорее идёт распределение по Гауссу. Есть мизерный шанс, что можно уложиться в минимальный срок (к примеру, окажется, что прогер забыл, что в крупном проекте уже есть такая функциональность, которая включается одним конфигом или за 5 минут найдёт либу, которая на 100% решает задачу) и мизерный шанс, что это уйдёт на очень долго (попадётся очень неприятный баг, который придётся долго и нудно отлаживать). В 90% случаев оно попадает где-то в середину. Можна называть или «8 часов», что будет означать пик Гауссианы, или «4-16», что будет означать две ближайшых ключевых точки. Всегда есть шанс не попасть. По сути, это одно и то же.
Оценка трудоемкости реализации отдельной фичи распределена не по нормальному закону. Слева оценка упирается в 0, справа имеет тяжелый хвост. Скорее это больше похоже на бета-распределение. Поэтому использовать матожидание несколько не корректно. Дял распределений с тяжелыми хвостами применяют более робастную оценку — медиану (50%.-квантиль).
Спасибо!
Отличный материал. Буду показывать студентам.
Отличный материал. Буду показывать студентам.
Еще имхо хорошо бы уметь читать между строк и иметь достаточное воображение, чтобы дополнить или предугадать, в какую сторону затем пойдет изменение требований.
Для многокомпонентных систем (особенно, разрабатываемых разными отделами, чужих компонент, или модулей, общающихся с внешним миром) — нужно подразумевать наличие способов доказательно защитить свою часть от нападок соседей (пригодится при отладке и сдаче всей системы) — то есть заранее заложится на детальное логирования обмена, средства усточивости к некорректным данным итд.
Образно говоря, прочитав в ТЗ указание на постройку двухэтажного дома, и зная алчность хозяина, не забыть оставить сверху хвосты арматуры на случай постройки третьего этажа, и фундамент сделать с запасом ;)
Для многокомпонентных систем (особенно, разрабатываемых разными отделами, чужих компонент, или модулей, общающихся с внешним миром) — нужно подразумевать наличие способов доказательно защитить свою часть от нападок соседей (пригодится при отладке и сдаче всей системы) — то есть заранее заложится на детальное логирования обмена, средства усточивости к некорректным данным итд.
Образно говоря, прочитав в ТЗ указание на постройку двухэтажного дома, и зная алчность хозяина, не забыть оставить сверху хвосты арматуры на случай постройки третьего этажа, и фундамент сделать с запасом ;)
Прошу прощения, промахнулся топиком
На шестой пункт многие отвечают, особенно самоуверенные сеньоры, что тестирование — это не их задача и время они тратить не будут. Немного продвинутые напишут самый тривиальный тест. В итоге, на базе codereview, ошибка находится за первые 5 минут. Думаю, к тестированию тоже можно применить ту же фразу про пользователя-психопата, который знает, где вы живете.
НЛО прилетело и опубликовало эту надпись здесь
Обращаю внимание на следующие аспекты:
1. Соблюдение договоренностей(в том числе не формальных) по ТЗ.
Случалось, что согласовывали одно, по факту человек делал другое. Почему? Потому что ему проще сейчас с тобой согласиться… а дальше делать как угодно. Это определенно проблема того, кто ставит задачу и лечиться прояснением ситуации с коллегой, в следущий раз человек явно высказывает свою позицию и исполняемое решение имеет действительно двухсторонний комитмент.
2. Самостоятельность — умение программиста преодаливать технические сложности реализации, не бояться совершать ошибки на пути поиска возможных решений.
3. Интерактивность. Случается «залипание» на задачах и есть разработчики, которые сообщат о возникших трудностях, есть и те, кто будут сидеть с проблемой пока сам не поинтересуешься прогрессом.
4. Умение формулировать проблему в технических терминах. Может показаться странным, но случается, что разработчик начинает говорить о коде и багах системы как о каких то монстрах, задача которых его запутать или одурачить. Помогают перерывы или выяснение действительных причин проблем в диалоге.
5. Ответсвенность. Определенно плюсом для разработчика, если он не просто передал задачу на тестирование(а случается что и об этом возникает необходимость напомнить), но к примеру может подойти к тестировщику и поинтересоваться, что там с его задачей(бывает что тестировщик нашел баг, но по ошибке заасайнил на другого и считай задача встала).
1. Соблюдение договоренностей(в том числе не формальных) по ТЗ.
Случалось, что согласовывали одно, по факту человек делал другое. Почему? Потому что ему проще сейчас с тобой согласиться… а дальше делать как угодно. Это определенно проблема того, кто ставит задачу и лечиться прояснением ситуации с коллегой, в следущий раз человек явно высказывает свою позицию и исполняемое решение имеет действительно двухсторонний комитмент.
2. Самостоятельность — умение программиста преодаливать технические сложности реализации, не бояться совершать ошибки на пути поиска возможных решений.
3. Интерактивность. Случается «залипание» на задачах и есть разработчики, которые сообщат о возникших трудностях, есть и те, кто будут сидеть с проблемой пока сам не поинтересуешься прогрессом.
4. Умение формулировать проблему в технических терминах. Может показаться странным, но случается, что разработчик начинает говорить о коде и багах системы как о каких то монстрах, задача которых его запутать или одурачить. Помогают перерывы или выяснение действительных причин проблем в диалоге.
5. Ответсвенность. Определенно плюсом для разработчика, если он не просто передал задачу на тестирование(а случается что и об этом возникает необходимость напомнить), но к примеру может подойти к тестировщику и поинтересоваться, что там с его задачей(бывает что тестировщик нашел баг, но по ошибке заасайнил на другого и считай задача встала).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Семь навыков профессионального программиста