Общение является ключевым элементом взаимодействия между людьми. Каким бы ни был ваш опыт в общении, иногда может возникать необходимость улучшить свои навыки, чтобы избегать конфликтов и более продуктивно решать возникающие проблемы. В этой статье я приведу механику возникновения конфликтов при общении, а также расскажу, что делать, чтобы их избегать.

Все мы стараемся сделать качественный сервис и хотим гордиться своим проектом. И для этого прибегаем к техническим решениям: автотестам на разных уровнях, оценке покрытия, сбору и анализу метрик. Это отличные активности, которые помогают проекту стать лучше. 

Но помимо hard-инструментов есть и soft-составляющая. Она не столь очевидна, но тоже помогает повысить качество сервиса. Меня зовут Николай Котов, я старший QA-инженер в Тинькофф и сегодня расскажу, как социальные связи влияют на качество проекта, и поделюсь советами по укреплению этих связей.

Забота об атмосфере в команде в большей степени лежит на тимлиде или продакт-менеджере, но работать над ее улучшением могут все. Если вам интересна эта тема, предлагаю вместе в ней разобраться.

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

Всем привет, дорогие друзья!

Приходилось ли Вам когда-нибудь тестировать формы авторизации?

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

Но ведь задача тестировщика постараться максимально точно и грамотно обозначить проблему!

Возможно ли это? Конечно!

Именно поэтому в данной статье мы разберем такой процесс как «Авторизация», а также поговорим о таких очень близких понятиях как «Идентификация» и «Аутентификация». Разберем, как всё это взаимосвязано и постараемся сделать это максимально просто и доступно для того, чтобы у вас не осталось никаких вопросов после прочтения данной статьи!

История дизайна в IT 1984 - 2024

Эта статья о том, как аналитик изучает основы SQL, какие допускает ошибки и как старается их исправить. В статье будет то, что помогает погрузиться в SQL впервые: схемы и примеры кода, понятия и определения, проблемы и решения. Статья рассчитана на аналитиков-новичков.

Предыстория: аналитик создает отчёты в BI для директора компании «ABC». Аналитик не умеет программировать и подключается к данным по инструкции. Директор требует срочно добавить в отчёт данные из 3 источников: SAP – объем выручки от продаж; HRLink – затраты на персонал; Битрикс – время обработки заявок. 

Аналитик ставит задачу data инженеру на добавление новых данных в BI. Data инженер – единственный специалист по работе с данными в офисе из 400 человек. Он критически оценивает сроки выполнения задачи и объявляет: «Минимум – 2 недели». Такой срок директора не устраивает. Инженер предлагает аналитику альтернативное решение...

Вот уже семнадцать лет я работаю графическим дизайнером. Как в найме, так и для частных заказчиков. Я не тот дизайнер, чьи работы лайкают на behance, растаскивают по доскам на pinterest и кидают референсами заказчику. Я обычный ремесленник и трудяга, продавший душу корпорации за комфортный соцпакет и стабильную зарплату. И нас таких – легион. Если вы хоть раз заказывали дизайн, вы почти наверняка имели дело с человеком вроде меня. В этой статье опишу жёстко и честно, почему работа с нами обычно строится через жопу.
И подскажу решение.

1. Думать о смыслах выполняемой работы

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

2. Прогнозировать результат своей работы

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

3. Уважать коллег, руководителя, подчиненных

Уважение – это априорное признание порядочности. Уверенность в том, что за словами и действиями коллег стоит желание сделать работу хорошо, признание наличия нужных для работы компетенций. Твой коллега говорит то, что он говорит, и делает то, что он делает, не потому, что он идиот, а потому, что находится в другом контексте, т.е. знает что-то, чего не знаешь ты, или не знает чего-то, что знаешь ты. И токсичность, и обидчивость в равной степени являются проявлением непрофессионализма.

Приветствую! Я – Данил Вильховский, генеральный директор компании по кастомной разработке программного обеспечения.

Нам часто приходят запросы на расчет стоимости проекта. Некоторые RFQ – настоящие шедевры: они детализированы, отлично структурированы. Иные же, скажем, требуют много уточнений. И это натолкнуло меня на мысль, что было бы неплохо создать небольшой гайд по составлению унифицированного и потому эффективного запроса цены.

Архитектор из крупного российского банка, предлагает простое представление, что делает архитектор решений, какими навыками он должен обладать, и как обычно устроен его день.

Кому-то статья поможет развеять основные заблуждения о профессии, кому-то составить карту развития в специальности, а кому-то наконец принять решение, хочет ли он/она быть архитектором решений.

Я не буду оригинален, если скажу, что сотрудники работают так, как ими управляют. Есть множество причин, почему сотрудники не могут делать то, что хочет от них руководитель, но сегодня я хочу поговорить о самой банальной и распространенной причине: сотруднику дали задание, которое он не умеет делать.

Привет, Хабр! Хотел бы поделиться с вами своим анализом работы с техническим долгом.

Как появился этот долг? Мы его взяли что бы поставить заказчику функционал раньше, чем мы бы смогли, если бы не «заняли». Так же как бизнесмен берет кредит для своей бизнес идеи.

? Экстремальное программирование — это пример разработки с кредитом

Статья‑гайд от ведущего.NET‑разработчика «ITQ Group» Александра Берегового.

Бывает, что нужно написать консольное приложение без использования IHost, но при этом иметь удобства IoC, поддержку конфигурационных файлов и переменных окружающей среды. В этой статье я и расскажу, как с минимальными усилиями сделать такое приложение.

Если вам кажется, что сон — не самое важное для продуктивной работы в течение дня (и даже недели), поздравляю, значит у вас нет проблем с недосыпанием. Всех остальных приглашаю к прочтению.

Раскрываем 12 кейсов проектирования спецификации REST API из практики red_mad_robot, которые помогут сэкономить время для разработки. А также объясняем, почему стоит следовать подходу contract first — писать спецификацию прежде кода.

В начале хочу сделать важную ремарку. Статья, которую вы прочитаете ниже, — это глава из книги, читатели которой уже погружены в контекст. Контекст того, что автор — это проектировщик информационных систем, который предоставляет сложную, дорогую и растянутую во времени услугу. Не всем подойдёт такой способ ведения дел. А теперь поехали:

Если ты теперь фрилансер и готов к волне заказов,
Размышляя, что же делать, чтоб заказ тебя нашёл.
Ты уже и так прекрасен! О тебе и так узнают!
Сядь на стул и жди клиентов, пусть стучатся сами в дверь.

Вопрос «Где искать клиентов?» — самый популярный среди начинающих фрилансеров. Раньше я отвечал на него так: «Определитесь с тем, какие именно вам нужны клиенты, и станет понятно, где их искать». Так себе ответ, не правда ли? Ведь откуда начинающему знать, какие именно ему нужны клиенты? Ему бы хоть каких-нибудь найти. Поэтому я копнул глубже и стал отвечать по-другому.

Не нужно активно искать клиентов. Клиенты сами вкладывают много сил в поиск исполнителей. Лучше сделать так, чтобы во время поисков они пришли именно к нам. Как это сделать? Заявить о себе как можно громче в тех местах, с которых обычно начинает свой поиск среднестатистический клиент. Если он будет просить рекомендаций у своих знакомых — значит, кто-то из них должен знать о нашем существовании. А если воспользуется поиском в Интернете, то рядом с названием услуги должно появиться наше имя.

Прежде чем заказов стало больше, чем я мог выполнять, мне пришлось рассказать о себе окружающим, написать десятки статей о профессии, неоднократно выступать на публичных мероприятиях, вести преподавательскую деятельность, сделать свой сайт и постоянно подбрасывать «дров в костёр», активно общаясь в профессиональных сообществах и периодически напоминая о себе существующим клиентам.

Хорошо работать в сильной команде.

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

И от чего же, одновременно, так тяжело работать в сильной команде?

Почему столько простоев на митингах? Почему уже два месяца невозможно закрыть задачу по ключевой проектной системе?.. И почему, в конце концов, откуда постоянно возникает это странное ощущение дежа вю при чтении кода? Ощущение "написано здорово - но чёрт подери, я ведь уже встречал что-то похожее на проекте..."

Знакомые чувства? Если да - вероятно, на вашем проекте не закрыта важная роль.