Naive Bayes Classifier

Giriş
Naive Bayes Sınıflandırıcısı hakkında bulduğum okuması en kolay yazı burada.

Decision tree VS Naive Bayes classifier başlıklı soru da bilgilendirici sayılır.

Naive Bayes ve K-means Clustering ilişkilidir

Predictive Models 

Açıklaması şöyle. Naive Bayes Classifier "yes or no" cevabı değil de olasılık ihtimali döndürür.

Top 5 Predictive Models

1. Classification Model: It is the simplest of all predictive analytics models. It puts data in categories based on its historical data. Classification models are best to answer "yes or no" types of questions.

2. Clustering Model: This model groups data points into separate groups, based on similar behavior.

3. Forecast Model: One of the most widely used predictive analytics models. It deals with metric value prediction, and this model can be applied wherever historical numerical data is available.

4. Outliers Model: This model, as the name suggests, is oriented around exceptional data entries within a dataset. It can identify exceptional figures either by themselves or in concurrence with other numbers and categories.

5. Time Series Model: This predictive model consists of a series of data points captured, using time as the input limit. It uses the data from previous years to develop a numerical metric and predicts the next three to six weeks of data using that metric.

1. Classification Nedir?
Bir olaya etiket vererek hangi kategoriye ait olduğunun belirlenmesidir yani tasnif işlemidir. Regression ile elimizdeki veriye bakarak, yeni bir değer tahmini yapılmasıdır.

2. Classifier Nedir?
Bu sınıflandırıcının (classifier) benim anladığım en önemli özelliği bir olayın herhangi bir kategoriye ait olması olasılığını hesaplaması.

Classifier özellikle robotik ve computer vision (bilgisayar görüşü/bilgisayarla görü) alanında çokça kullanılır

3. Conditional Probability
Naive Bayes' i anlamadan önce Conditional Probability kavramını anlamak gerekir. Conditional Probability daha önce olmuş bir olaya bakarak bir sonraki olayın gerçekleşme olasılığını bulur.

Örnek
Mesela bir demokrat senatörün kadın olma olasılığı nedir sorusu şöyle cevaplanır.
Önce senatörün demokrat olma olasılığını buluruz. Daha sonra demokrat olduğunu bildiğimiz bu kişinin kadın olma olasılığı ile çarparız.

P(Democrat & Female) = P(Democrat) x P(Female / Democrat)

Bir başka açıklama şöyle.

Bayes Rule: P(A|B) = P(B|A) * P(A) / P(B)
The probability of A (when B has occurred) = the probability of B (when A has occurred) *  probability of A (anytime) / probability of B (anytime)

4. Naive Kelimesi Nereden Geliyor?
Soru şöyle

Some articles say that naive Bayes is naive because of "independence of attributes". Whereas others say "independence of attributes within a class". Can anybody please clear this confusion? Thanks

Açıklaması şöyle

Naive Bayes doesn't assume independence of attributes ... It assumes conditional independence (or what you call independence within a class). This allows us to write the likelihood in the bayes rule P(X | Y) as the product of all P(Xi | Y), where X = (X1, ... Xi, ... Xn) and n is the number of attributes.

Bu açıklamalarda "Conditional Independence" önemli. Çünkü Naive Bayes kullanırken yapılan en önemli kabul "niteliklerin birbirinden bağımsız olduğudur". Yani nitelikler birbirlerini etkilemez. Dolayısıyla sonucun çıkma olasılığı o sonuca etkiyen tüm niteliklerin olasılıklarının çarpımıdır.

Örnek

Elimizde şöyle bir şekil olsun. Şekildeki X1, X2...X5 conditionally independent yani bir kişi Flu X1 ve X2 ve ... X5 belirtileri gösterebilir/göstermeyebilir.

Olasılık Gösterimi Nasıl ?
Naive Bayes sınıflandırıcısını açıklarken kullanılan olasılık gösteriminin açıklaması şöyle.
P (A|B) : B kümesinde A'nın olma olasılığı demek.

Formül Nasıl Çalışır
(Kategorinin olma olasılığı * elimizdeki niteliklerin olma olasılığı) / küme sayısı gibi düşünülebilir.

Burada nitelik yukarıdaki X1...X5'e denk geliyor.

Örnek
Aşağıdaki şekilde 15. günde eğer hava koşulu Outlook = Sunny, Temperature=Cool, Humidity=High, Wind=Strong ise Tenis oynama olasılığı hesaplanıyor.

Hesaplama şöyle: Her niteliğin kendi olasılık kümesinin büyüklüğüne bölündüğüne dikkat etmek lazım.
Toplam veri sayısı = 14
Toplam Yes sayısı = 9
Toplam No sayısı = 5
Outlook = Sunny sayısı = 2

Temperature=Cool sayısı = 3

Humidity=High sayısı = 3

Wind=Strong sayısı 3

Yes çıkma olasılığı P(y)=9/14 x 2/9 x 3/9 x 3/9 x 3/9=0,0053

No çıkma olasılığı P(n)=5/14 x 3/5 x 1/5 x 4/5 x 3/5=0,0205

Yani tenis oynanmama olasılığı daha yüksek.

Scrum

Scrum'ı Terk Etmek

2021 yılına doğru Scrum'u kötüleyen yazılar çoğalmaya başladı. Zamanı gelince de Scrum şöyle kötü böyle işe yaramaz diye daha fazla yazı göreceğiz. Abandoning Scrum okunabilir.

Scrum Sabit Fiyat ve Takvim Projeler için Kullanılır mı ?
Kullanılabilir. Kapsam (Scope), Takvim (Schedule) ve Bütçe (Budget) ayarlandıktan sonra kullanılmaması için bir sebep yok.

ABD'de ve Türkiye'de savunma projeleri sabit fiyat/takvim ve şelale modeline göre kurgulanırlar. Tüm projenin olmasa bile geliştirme aşamasının scrum tabanlı iterative user story'leri olarak gerçekleştirilmesi mümkün.

Burada dikkat edilmesi gereken nokta Scrum'ın, Half Arsed Agile şekline dönüşmesi.

Scrum ve XP Arasındaki Farklar

Scrum ve XP çevik süreçler. XP daha çok kodlamaya yönelik faaliyetleri ön plana çıkarıyor. Örneğin XP'de önce test (test first) çok önemli, ama Scrum kodla ile ilgili bir şey söylemiyor. Dolasıyla bazı projelerde XP ve Scrum birlikte kulanılabiliyor. Aslında XP refactoring'i öne çıkardığı için belki iyi bir şey yapıyor. Refactoring bize kodu tekrar yazabilme imkanı sunuyor. Aslında bir yazılımın 5 kere baştan yazıldıktan sonra hazır olduğuna dair bir yazı var. Yazı şöyle

However, software development doesn't obey by the normal laws of nature. For instance, every time you re-engineer your software from scratch, you're destined to implement it 10x better, 10x faster, and 10x more stable - At least up to some "n number of rewrites". Hence, my proposition, is to create the same software 5 times, before you're happy with your end result, and willing to label it as "production ready". In fact, if you haven't created the same software at least 5 times, I'd argue it's probably garbage anyways.

Destekleyici bir deney şöyle

One study once asked random strangers on the street to create ceramics pottery. 50% of the people were told to spend 8 hours creating one single cup and try to create it "perfect", while the rest of the group were told to create as many cups as they could. Afterwards they had professional ceramics teachers evaluate the results, and paradoxically, the best quality was consistently found amongst those who had been told to create many cups.

Scrum ve İletişim

Scrum iletişimi defalarca vurguluyor. Çoğu başarısızlığın altında iletişim problemi de bulunuyor. Bir açıklama şöyle. Burada bireyler ve iletişim vurgulanıyor.

From the four values:

...

Individuals and interactions over processes and tools

 Bir açıklama şöyle. Burada yine iletişim ama yüz yüze iletişim vurgulanıyor. Uzaktan çalışma ortamında bunu direkt yüz yüze değil de video konferans şekilde anlamak lazım.

From the 12 principles:

...

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Scrum Başarısızlıkları
Scrum Başarısızlıkları yazısına taşıdım.

Scrum ve Critical Path
Şelale projelerde "critical path" - yani mutlaka bitmesi gereken birbirine bağımlı en uzun işlevler zinciri - önceden belirlenir. Bu öncelikli işlerin bitmesi için tedbirler alınır. Scrum'da critical path kavramı yok.

Scrumdaki Roller
Roller yazısına taşıdım.

Sprint ve Mimari
İlk sprint'lerde mimariyi oturtmaya çalışmak gerekir. Sadece eldeki story'e odaklanılırsa genel işleyiş, kural ve kararlar gözden kaçabilir. Yukarıda da yazdığım gibi bir yazılım mimarının bulunmaması Scrum'ın zayıflıklarından birisi, ancak ilk sprint'lerde bir mimarı çalışması yapmak ta zaten hemen her yazılım projesinde olan bir şey.

Sprint Planlama Toplantısı
Sprint Planlama Toplantısı yazısına taşıdım.

Günlük Toplantılar
Günlük Toplantılar yazısına taşıdım.

Retrospektif Toplantısı

Retrospektif Toplantısı yazısına taşıdım.

Backlog
Product Owner yazısına taşıdım.

Burndown Chart
Burndown Chart yazısına taşıdım.

Velocity

Hızın sabit tutulması için gerekli şeylerden birisi de kodun sürekli refactoring'e yani yeniden düzenlemeye tabi tutulmasıdır. Scrum refactoring'den açıkça bahsetmez. Bu konuyla daha çok Extreme Programming ilgileniyor. Ancak refactoring technical debt'in yani teknik borcun temizlenmesi için gereklidir. Temizlik ise proje ilerledikçe hızın düşmemesini sağlar.

Velocity Bir Müddet Sora Kendi Kendine Ayarlanır
Açıklaması şöyle.

A team brings 30 story points in to a sprint but only completes 25 story points

The rolling average of velocity for the team is reduced from 30 to 27

The team brings 27 story points in to the next sprint and manages to complete 24 story points

The velocity again falls, down to 25

Sprint Süresi
2,4,6 haftalık sprintler olabilir. Sprint süresi değiştirilebilir ve ekip tarafından belirlenir. Açıklaması şöyle

The Scrum team decides the length of the Sprint (dev team + PO + SM). They do the actual work, so they choose the duration of the time-box they feel more comfortable with in order to produce a product increment.

With that being said, there are of course all sorts of other things happening in the company that may influence what decision the Scrum team makes. You mention some of them in your question. If that happens, the team can always change the sprint duration. You don't need to keep the same length all throughout the project. You start with whatever works for you, then inspect and adapt.

Sprint tarihleri mutlaka görünür bir yerde olmalıdır. Tatilleri de dikkate almalıdır.

Sprint 14: November 18th—December 2nd (10 days)
Sprint 15: December 2nd—December 18th (11 days; december 4th: attending the conference in NYC)

Sprint süresi uzadıkça geribesleme döngüsü de uzar. Sprint içindeki geliştirme saati aşağıdaki gibi hesaplanabilir.

DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevs

1,2,3 haftalık sprintlerde geliştirme için ne kadar saat ayrılabildiği görülüyor. CeremonyOverhead haftada 4 saat alıyor diye düşünülmüş. Örneğin sadece günlük toplantılar haftada 1-2 saat alır.

1 week: ((8 * 5) - 4) *.8 = 28.8 hours or 5.76 hours per day.
2 weeks: ((8 * 10) - 4) *.8 = 60.8 hours or 6.08 hours per day.
3 weeks: ((8 * 15) - 4) *.8 = 92.8 hours or 6.18 hours per day.

Bazı uygulamalarda 4 sprint'ten sonra 1 hafta dinlenme ve hazırlanma amacıyla boşluk bırakılıyor.

Story
Story yazısına taşıdım.

Story Point
Story Point yazısına taşıdım.

Sprint İçinde Herkesi Meşgul Tutma
İdeal bir ortamda herkesin iş yükünün eşit olması beklenir. Böylece işini erken bitiren, ne boşta kalır ne de ben ne yapacağım diye soru sorar. Ancak gerçek hayat böyle değil. Bu yüzden işini erken bitirenlerin ne yapması gerektiğine dair sorular var. Fikirler birbiri ile çelişebiliyor. Ben de hepsini listemenin daha iyi olacağını düşündüm.

• Mesai saati dışında backlog'dan önem sırasına bakmaksızın iş çekip bitiren birisi hakkında fikirler belirtilmiş. Genel eğilim bırak yapsın yönünde.
• İşini erken bitiren birisinin backlog'dan bir iş yapmasına itiraz edenler de var. 
• Boşta kalanlar bir sonraki sprint için araştırma yapabilirler diyenler de var. 

Bakım ve Hata Temizleme
Projeleri hayata geçtikten sonra bakım ve hata temizleme süreci başlar. Scrum sadece geliştirme aşamasında değil, bu aşamada da kullanılabilir. Kullanılan yöntem geliştirme süreciyle aynı. Bu sefer bug backlog oluşturuluyor Product Owner hataları önemine  göre sıralar. Kimin hangi hatayı çözmesi gerektiğine yine ekip kendi içinde karar veriyor.

Eğer geliştirme aşamasında hatalar gelmeye başlarsa, hatalar da story formatına dönüştükten sonra bir sonraki sprint'e dahil edilirler.

"If at a later date QA (or worse yet a customer) finds a bug, the report goes into a bug tracking database and also becomes a story which should be prioritized just like all other work."

NVIDIA thrust Kütüphanesi

Giriş
Quick Start Guide yazısını okumak lazım. thrust CUDA ile çok kolay kullanılıyor. Şöyle yaparız.

$ nvcc -o t1254 t1254.cu

Kurulum
Bu kütüphane sadece header dosyalarından oluşuyor. Açıklaması şöyle.

Since Thrust is a template library of header files, no further installation is necessary to start using Thrust.

Sadece CUDA Toolkit kurulumu gerekli.  Açıklaması şöyle.

Installing the CUDA toolkit should be sufficient.

GPU Güç Tüketimi
GPU'lar çok fazla güç tüketirler. Açıklaması şöyle. GPU'larda çok fazla sayıda transistör bulunur

A GPU is basically a LOT of simplified CPUs in parallel. Each of them is not as capable and flexible as a real CPU, but there are thousands of them to give this massive parallel computing performance.

But this also means that it takes many billions of transistors to build a modern GPU. And for logic chips we use FETs, so with every clock cycle all the billions of gate capacitances have to be charged and discharged. This is where the large amount of power is going.

Embarrassingly Parallel İşler
Bazı işler GPU için uygun değildir. Açıklaması şöyle

GPUs work with the model SIMD (single instruction multiple data) i.e. they execute an instruction over multiple data. To give an idea: under CUDA technology when you have got an if-then-else condition the two branches are executed in sequence over the respective data.

In your question, the condition to favor a CPU suggests a MISD or MIMD model, i.e. different instruction over the same data or different data.

thrust::device_vector Sınıfı
GPU bellekteki bir alanı temsil eder. Şu satır dahil edilir.

#include <thrust/device_vector.h>

Şöyle tanımlanır.

const int dsize = 1000;
thrust::device_vector<int> dVector(dsize, 1);

thrust::host_vector Sınıfı
Ana bir alanı temsil eder. Şu satır dahil edilir.

#include <thrust/host_vector.h>

Şöyle tanımlanır.

const int hSize = 10;
thrust::host_vector<int> hVector(hSize);

thrust::copy_n metodu
Şöyle yaparız.

thrust::device_vector<int> d_r = ...;
int rsize = ...
thrust::copy_n(d_r.begin(), rsize, std::ostream_iterator<int>(std::cout, " "));

thrust::exclusive_scan metodu
Şöyle yaparız.

thrust::exclusive_scan(VAR2.begin(), VAR2.end(), VAR1.begin(), 0);

thrust::inclusive_scan_by_key metodu
Şöyle yaparız.

template <typename T>
void scan_horizontally(size_t m, size_t n, thrust::device_vector<T>& d_data)
{
    thrust::counting_iterator<size_t> indices(0);

    thrust::inclusive_scan_by_key
        (thrust::make_transform_iterator(indices, row_index(n)),
        thrust::make_transform_iterator(indices, row_index(n)) + d_data.size(),
        d_data.begin(),
        d_data.begin());
}

Girdi ve çıktı olarak şunu alırız.

Input: [0, 1, 2, 3
        4, 5, 6, 7
        8, 9, 10, 11,
        12, 13, 14, 15]

Output: [0, 1, 3, 6
        4, 9, 15, 22
        8, 17, 27, 38,
        12, 25, 39, 54]

thrust::partition_copy metodu
Şu satırı dahil ederiz.

#include <thrust/partition.h>

Önce partition işlemi için kullanılacak metod yazılır.

struct is_even {
 __host__ __device__ bool operator()(const int &x) { 
    return (x % 2) == 0;
  } 
};

Daha sonra 3 tane vector tanımlanır.

const int N = 10;
thrust::host_vector<int> hVector = ...;


thrust::device_vector<int> dVector      (hVector);//Copy
thrust::device_vector<int> dVectorEvens (N/2);
thrust::device_vector<int> dVectorOdds  (N/2);

Sonra dVector bölümlenir.

thrust::partition_copy(dVector.begin(), dVector.end(),
                       dVectorEvens.begin(), dVectorOdds.begin(), is_even());

thrust::reduce_by_key metodu
Şöyle yaparız.

thrust::reduce_by_key(
    keys_input.begin(),
    keys_input.end(),
    values_input.begin(),
    thrust::make_discard_iterator(),    values_output.begin(),
    thrust::equal_to<int>(),
    thrust::plus<int>());

thrust::transform metodu
Önce namespace dahil edilir.

using namespace thrust::placeholders;

Daha sonra algoritma çağrılır.

thrust::transform(VAR1.begin(), VAR1.end(), VAR1.begin(),  _1 += 1);

Ekip Kurma - Team Building

Giriş
Team Building ile ilgili bir yazının özeti şöyle.
1. Frederick Winston Taylor 1880'lerde insanları değiştirilebilen makine parçaları gibi gören araştırmalar yapmış. Amaç tam optimizasyon

2. Bruce Tuckman 1965 yılında ekibin bir araya gelmesi için geçtiği aşamaları yazmış. Bu aşamalar

1. Forming
2. Storming
3. Norming
4. Performing

3. Patrick Lencioni 2002 kötü bir ekipteki sebepleri yazmış.

The Absence of Trust
The Fear of Conflicts
The Lack of Commitment
The Avoidance of Accountability
The Inattention to Results

3. Dan Pink yazılım dünyasında motivasyon sebeplerini yazmış.
Yeterli para kazanmaya başladıktan sonra insanları motive eden şeyler şunlar.

Autonomy - kendi hayatımızı yönetmek
Mastery - uzmanlaşmak
Purpose - diğerlerine yardım etmek

4. Malcolm Gladwell The Tipping Point kitabında ekipteki "connector" tipleri açıklamış. Açıklaması şöyle

He regarded connectors as, obviously, people who know a lot of people, but more importantly, people who can connect different worlds and spot things in one world that can be applied in another.

Or as Gladwell himself said, "connectors are people who link us up with the world. People with a special gift for bringing the world together."

Broker tipler'in açıklaması şöyle.

The researchers identified three main kind of brokers:

1. Intermediaries: These people help to bridge the gaps within any social structure, and therefore build positive connections with others to help forge new relationships via introductions and recommendations.
2. Conciliators: These people, on the other hand, tend to work more in mending relationships that have hit the rocks. They mediate and help to forge compromises and solutions to conflicts, thus helping relationships to recover.
3. Dividers: These people are perhaps the most nefarious of all. They tend to have a Machiavellian bent to them and seek only to create friction and conflict, perhaps through gossip or some other means to sew discord among the group.

İyi Bir Ekip Nasıl Oluşur?
İyi bir ekip neden önemli sorusunun cevabı şöyle. Çünkü günlük hayatta beraber çalıştığımız insanlar, çalıştığımız şirketten daha önce geliyor.

People don't leave bad companies, they leave bad "bosses".

Aşağıda iyi bir ekip oluşturmak için gereken bileşenler mevcut.

Ekipteki Ünvanlar ve Görevleri
Not: Bazen ünvana sahip olmayan birisinin de aşağıdaki görevlerden bir veya birkaçını yerine getirmesi gerekebilir.

Lead Engineer (Teknik Lider)
Diğer görevlerinin yanında şirkette neler oluyor, yeni işler, heyecan verici konular hakkında ekibi bilgilendirmesinde fayda var. Bu işi kurumun yapılanmasına göre teknik liderinin dışında başka bir kişi de üstlenebilir - örneğin matris yapılanma bir başkası bu görevi üstlenir - ancak atlanılmaması gereken bir nokta olduğunu düşünüyorum.

Team Lead (Takım Lideri)
Takım Lideri yazısına taşıdım

Planlama
Ekip Kurma - Team Building ve Planlama yazısına taşıdım.

Sonuç Odaklılık
Takımın sonuç odaklı olup olmadığını anlamanın basit bir yolu, takım liderinin olmadığı zamanlarda bir araya gelip toplantı yapılıp yapılmadığına veya karar alınıp alınmadığına bakmaktır. Takım bu faaliyetleri yapamıyorsa bu takımın sonuç odaklı değildir.

Kişisel Performans
Yeterince verim alınmayan kişilerin iş yapmaya zorlanması gerekebilir. Bir yöntem kişiye zaman kısıtları ve hedefleri konulması. Açıklaması şöyle.

The problem here is not the web browsing, but that his work output is not satisfactory.

You need to address this like any other performance issue: set clear expectations and hold them accountable. For example, agree on what you expect to be done by Friday and get them to commit to it. If he delivers, all good, just keep doing this. If he does not, ask them why and figure out what you both can do about it. Maybe he needs to spend less time web browsing, maybe it's something else entirely.

İletişim
Ekip Kurma - İletişim yazısına taşıdım.

Kaynak Kod


Kaynak Kodun Değiştirilmesi

Kaynak kod ekibin malı olarak görülürse, bence daha iyi netice alınıyor.

Ekip içindeki "Karar Verme" ve "İletişim" güçleniyor.

Kodun belli bir kısmını yazan kişi, o yazılımı parçasını kendi malı olarak görmemeli. Bu durum özellikle altyapı olarak görülen kısımlarda ortaya çıkıyor. Altyapıyı hazırlayan kişi kodu sahipleniyor ve kimsenin ellememesini istiyor. Bazen de "daha iyi" olacağını düşündüğü değişiklikler yapabiliyor. Bence eğer değişiklik yapılması gerekiyorsa, örneğin sınıfı isimlerinin, metodlarının değiştirilmesi ekip içinde konuşulmalı ve ekibin kararına uygun olarak gerçekleştirilmeli veya gerçekleştirilmemeli.

Ekibe Girenler Ve Çıkanlar

Ekibe Yeni Katılan Birisinin Hemen Ayrılması

Ekibe yeni katılan ve iyi işler çıkarması beklenen birisinin, daha iyi bir fırsat bulduğunu söyleyerek kısa bir zaman çalıştıktan sonra ayrılmak istemesi karşısında ne yapılabilir ? Son bir kaç ayda, karşılatığım bu olay ekip açısından planları alt üst edici. Kalanlara güven verici, bir konuşma yapılmasında fayda var.

Uzun Zaman Çalışmış Birinin Ayrılması
İster istemez kurumsal hafızanın da ayrılması anlamına gelir. Ayrılan kişiye bir plaket verilmesi, merasim düzenlenmesi herkes için güzel bir anlam taşır.

Diğer Bazı Davranışlar

Aşağıda sıklıkla yaşanılan bazı davranış örneklerini sıralamak istedim.

Toplantı
Toplantının zamanında başlamaması problem olabilir.

Üst Yönetime veya Müşteriye Karşı Çatlak Ses
Toplantılarda yöneticileri zor durumda bırakan bir durum. Çatlak ses dışarıya karşı olduğu zaman, suistimal olabiliyor. Yöneticinin önemli toplantılar öncesinde bir prova yaparak, çatlak ses çıkmaması iyi bir tedbir olabilir.

Ekibe Yeni Katılan Birinin Çok Soru Sorması
Ülkemizde projeler genellikle soru sorarak yol yordam bulma şeklinde ilerliyor. Projeye yeni katılan birisi haliyle bir çok soru sorma ihtiyacı hissediliyor. Soru ve cevaplar e-posta ile oluyorsa daha da sıkıntılı durumlar olabiliyor

Soru soran kişi :
Soru soran kişi açısından bakılınca gerçekten yardıma ihtiyacı olabilir. Yalnız soru sorarken dikkat edilmesi gereken husus, sorunun ilgili kişiye sorulması olmalı. Bazen soru ilgili olmayan bir kişiye sorulursa, soru sorulan kişinin sinirli bir tavır aldığını görüyorum. Bu durumda ekip içinde yayınlanan ve sorumlulukları gösteren bir memo faydalı oluyor.

Soru sorulan kişi :
Hiç bir zaman ilgilenmek istemeyebilir, başı sürekli çok kalabalık olabilir vs. gibi nedenli nedensiz sebepleri var. Durumu gözlemleyen yöneticinin ekibin önünü açıcı bir tedbir alınmasında fayda var.

Eğer soru sorulan kişi, yeterincen uzun ve tatmin edici cevaplar verdikten sonra halen sorulara muhatap oluyorsa ve artık cevaplamak istemiyorsa, "şu ana kadar nasıl bir araştırma yaptın", "google'da aradın mı" gibi yönlendirici sorular ile kişiye artık yeterince destek olduğunu hatırlatabilir.


Projedeki bir hatanın sahipsiz kalması

Bazen ufacık bile olsa bir hata, ilgisiz birisinin önüne düşüyor. Konu hakkında bilgisi olmadığı için, bilgili olduğunu tahmin ettiği bir kişiden yardım istiyor. İkinci şahıs da aslında konuyu bilmiyor ve "bana ne ,ben mi yaptım" tarzından yaklaşıyor. Bu durum problemi çözmesi gereken ilk kişi için yıpratıcı bir hal alıyor. İlk şahıs daha yumuşak başlı davranarak, " senin çözmeni beklemiyorum ama gel beraber bakalım" diye konuya yaklaşabilir. Yöneticiye yansıtmadan durumu çözmek daha kolay olabilir.

Fazla Mesai/Vardiya
Fazla Mesai ve Vardiya yazısına taşıdım.

Çalışma Arkadaşlarının Değerlendirilmesi
Belli dönemlerde çalışma arkadaşlarının birbirlerini değerlendirilmesi faydalı olur. Puanlama usûlü şirketten şirkete değişir. 1-5 arasında not verilmesi istenebilir.

1.Yönetici Değerlendirme Formu
Planlama,  yönlendirme
İletişim
Liderlik
Bilgi Seviyesi
Ekibini Sahiplenme
Süreçlere Uyma

2.Teknik Lider Değerlendirme Formu
Şu özellikleri değerlendirilebilir.
Planlama, yönlendirme
İletişim
Liderlik
Bilgi Seviyesi
Ekibini Sahiplenme
Süreçlere Uyması

3.Takım Arkadaşı Değerlendirme Formu
Şu özellikleri değerlendirilebilir.

Sorumluluk Alması
Takım Çalışması
Bilgi Edinme ve Paylaşım
Yenilikçilik
Gerbeslemeye Açıklık
İletişim
Süreçlere Uyma

Kavga ettiği için ekiptek ayrılan birinin değerlendirmesi de haliyle düşük olacaktır. Yeni ekibe geçen bu kişiyi eski çalışma arkadaşlarının verdiği notlara göre değerlendirmek yanlış olabilir.

Kişisel Değerlendirme
Her bireyin kişisel değerlendirmesini de yapmak gerekir. Kişiden şu başlıklara göre kendisini değerlendirmesi istenebilir.

Direkt Sorumlulukları
Direkt İlgili Olmayan Sorumlulukları
Başarıları
Hedefleri
Kullanılan Metod, Araç, Kaynaklarda Gelişimi

Şirket Değerlendirmesi
Üst yönetime sunulabilecek şekilde şirketin olumlu ve olumsuz noktaları da değerlendirilebilir.